Kirk, Ani
There is one small complication with keeping the most recent
alertid for each Object: it requires updating existing rows.
It would be nice to have the design of largest tables such that
each row is written one, and kept read-only after that.
Such approach guarantees reproducibility, and make it more
manageable (easier to replicate and distribute).
Changes/updates would be done through versioning, but
I'm not sure it is worth using versioning in this case.
Jacek
Kirk D Borne wrote:
To reiterate other people's comments: yes, there may be as many
as 10,000 alerts per night, hence more than 10^8 events for the
lifetime of the survey. It makes sense that one alert
corresponds to one object. But one object may have many
alerts (e.g., a new supernova may be "alerted" for ~100 nights
in a row; or an asteroid may be "alerted" every time it is in
the FOV).
It is imperative to have the objectid in the alert table.
One can then join on the object table to get the corresponding
object information. But I don't see that the converse is
equally useful --> i.e., having the alertid (for *each* alert)
in the object table. However, I do like Ani's suggestion of
having the most recent alert's alertid in the object table.
- Kirk
----- Original Message -----
From: Ani Thakar <[EMAIL PROTECTED]>
Date: Thursday, August 17, 2006 1:03 pm
Subject: Re: [LSST-data] Re: cpu for queries
i agree with maria that there doesnt need to be a separate table
to map
objectid<->alertid, but it may be useful/convenient to keep the
first or
last alertid for each object in the object table, so for example
users
can query on whether an object has ever had an alert or the last
alert
for an object. if this is not a useful science question then
alertid
doesnt need to be in the object table, only objectid in the alert
table.
ani
On Thu, 17 Aug 2006, Tim Axelrod wrote:
Jacek,
I will look it up later (I am on a telecon), but my memory is
that the
alert rate is about 100,000 per night, not 10!
An alert should apply only to a single object.
Tim
Jacek Becla wrote:
Maria,
Can an alert correspond to more than one object?
Probably not. Then you don't need a new table only and
objectID in
the Alert table
That would work if the answer is 'no', especially given
that the Alert table will be compact. (Can someone remind
me how many alerts we expect per night? Assuming 10,
the Alert table will be growing 3,000 rows/year,
that is nothing.)
We should then keep the bit in the Object table
indicating whether there was an alert for given Object
(as Tim suggested)
thanks,
Jacek
--
Aniruddha R. Thakar, Research Scientist
Center for Astrophysical Sciences, JHU, Bloomberg 375
3701 San Martin Drive, Baltimore MD 21218-2695
410-516-4850, Fax: 410-516-5096
[EMAIL PROTECTED], http://www.sdss.jhu.edu/~thakar
-------------------------------------------------------------------
----
When I was a boy I was told that anybody could become President;
I'm
beginning to believe it. [Clarence Darrow]
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
