Nicole and Russ, I looked at your DB schema. Here are my initial ideas/notes on how to merge it with the prototype schema:
1) Your WCS tables (NOAO4mWCS, TangentWCS, APO2_5mWCS, MSO50inWCS) can be "merged" into a single "entity" in the prototype schema (unless we envision multiple WCS solutions for LSST). I used the word "entity" and not "table", because we need to think more about whether to keep the resulting WCS info in a separate table or as part of the image table. 2) Same goes for PSF model tables (DophotPSFModel, DaophotPSFModel, PhotoPSFModel) -- a single table/entity can be made from these three with attributes relevant to LSST PSF algorithm. 3) Your PipelineRun and AlgRun tables capture provenance data, and are very useful. I will try to incorporate most of their attributes into the prototype schema. Your TieImageToAlgRun table appears redundant: couldn't Image and AlgRun be tied directly (AlgRun will have pointer to imageID)? 4) Your Image table is the one I looked at more or less in detail, and have more specific comments about it: - I assume your image table relates to a single amp (it has ccd and amp attributes). It might be advantageous to have a separate table for the whole FOV assembly -- that way one does not need to duplicate attributes common to the whole mosaic (like ExpTime, UT1, etc) - A bunch of varchar fields related to names of files are better taken out to a separate table and linked to this one by a foreign key. The reason is (variable) text fields slow down the query performance. - Run/Rerun attributes seems redundant -- maybe Run only is enough? - HTMIDLL/LR/UL/UR appear to be an attempt for spatial indexing (using HTM). I do not want to say anything bad about HTM, but there are also built-in efficient spatial indexes in most DB engines (using e.g. geometry data types and R-trees). - Az, Alt encode telescope pointing. Was there a specific reason you used them, as opposed to RA, Dec? - There are a few attributes that I do not understand (and comments did not help either): camcol, TAI, BinX, BinY - An interesting point to me is that you keep as an attribute the name of the WCStable. While this is ok, it does not allow you to use a table JOIN on this attribute, because JOIN cannot operate on table names (I think). It seems to me you have to query this field and interpret it outside of the database before you can use it to form a JOIN query. I'll look at the object table next. Overall, I think it's fairly straightforward to merge the two schemas. Please let me know if you agree/disagree with my notes above. Cheers, Sergei. > > http://www.astro.washington.edu/rowen/DBDocs/UWDatabase.html > > _______________________________________________ > 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
