I found the discussion enlightening and daunting, in about equal parts, as
all the things this database ought to be able to do became manifest. Some
of the issues raised were
1. Should database services do format conversion (e.g. string to float)?
If so, data type needs to be specified in xml file, which might be
cumbersome. On the other hand, would be nice to do verification
of input early on rather than making each application do it.
2. Should input to dbs (e.g., xml file) imply something like a class
hierarchy, or is this all left to layers above the dbs?
3. There is a need for
* co-existing databases with different types of information
(e.g. one with generator parameters, another with detector
description)
* a hierarchy among such databases (e.g., some way to keep
track of the fact that switching to a different detector
will imply switching to a different set of smearing
parameters)
* co-existing databases with (roughly) the same kind of
information, e.g. one describing the Small Detector and
another the Large Detector
Is there anything else that belongs on this list?
The consensus was that we need to work out a database structure and perhaps
associated xml files for a test case or two before trying to decide more
design issues.
Joanne
|