Hi Konstantin
After an introduction to the wonders of your DAQ system by Anders
Holm, I have some questions concerning the run database.
First let me complement you on the DAQ system. As Anders pointed out,
it seems that you have carefully thought thinks through, and
considered any eventuality.
Concerning the Run DB. If you haven't made a decision on how to go
about that DB, I suggest we somehow use Objectivity for that
database. Let my try to summerize the reasons why I think this is a
good idea.
* Since the RunDB is fairly simple, it should prove to be a simple
task to implement such a DB in Objectivity. By simple, I mean that -
as I see it - that the information (or entries) in such a DB would
be reather uniform and simply keyed. I could imagine a doubly linked
list of C++ classes like:
class RunEntry {
private:
int fRunNumber;
time_t fStartTime;
time_t fEndTime;
string fTrigger[];
string fAuthor;
string fComments;
// and other simple fields that might be needed.
RunEntry *fNextEntry;
RunEntry *fPreviousEntry;
public:
RunEntry(int no, time_t start, string trigs[],
string author, ...);
void SetEndTime(void);
time_t GetStartTime(void);
// and other similar Get and Set methods
};
and no other kinds of objects need to be stored (appart from
internal Objectivity indicies to facilitate fast lookups and
queries.)
* The way that I'm currently implementing the Calibration DB, one
would do lookups on a specific time (infact a UTC time). However,
when doing actual data chrunching, mining, and analysis, one would
properly do query bassed on run numbers, triggers or run types, or
any combination of these, and not on time. Hence my idea is
something like this:
- One does a query on the RunDB, using some combination of lookup
keys, and a (or possibly a set of) RunEntry object(s) is(are)
returned.
- Using the fStartTime, and fEndTime of the RunEntry object(s), the
program does a query on the CalibDB for calibrations valid in
that time period, for any detector needed.
Now this is also possible using a releational DB for the run
information. But, since using a uniform set of methods inside
BRAT/ROOT is wanted, one could do better using the same interface to
both the RunDB and the CalibDB - I believe. Ofcourse, if one could
somehow incorporate a releational DB (SQL) query into BRAT/ROOT, one
could properly do just as well.
* Still, if a releational DB (SQL) query is build into BRAT/ROOT,
there is still one more argument for the use of Objectivity: If one
really wanted to do so, one could add references to the run entries
to specific calibration, using any kind of relation (uni-directional,
bi-directional, 1-1, 1-n, n-1, n-n).
* Finally, there is a way to do SQL queries on an Objectivity
database, using the Objectivity/SQL++ component of
Objectivity. However, I know nothing of this component, since it
isn't avaliable yet on Linux, at least not at RCF!
Anyway, these are a couple of thought I had one the subject. If a
decision has already been made, please let me know. I believe you
advocated for a relational RunDB, when we talked this summer, but
maybe my points can make you reconsider.
Anyway, this is just me thinking out loud.
Live long and prosper.
Christian
----------------------------------------------------------------
Christian Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23. 1, th Office: (+45) 353 25 307
DK-2200 Copenhagen N Email: cholm@nbi.dk
Denmark Homepage: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Tue Feb 01 2000 - 20:35:04 EST