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
