Greg Caulton wrote: > One reason for the question was that it wasn't clear whether the > atxxxx uniquely identifies a concept within the ADL. I think it still > does, but it can have different context depending on where it occurs. > it doesn't in general. In certain archetypes it happens to, but you should not use that in any way to write software. > Implementing a hierarchy of information (information model) using > entity relationships (data model) is common place. > well, yes and no. If you try to make the relational model have anything to do with the clinical information model, you will usually hit a wall. Instead, relational databases can be used very effectively as a low-level store of blobs keyed by path. I wrote a web page on this aproach which we still have not transferred to the new site, but will in the next week or so - it may shed some light on the matter. > The argument of Object databases versus Relational databases is an old > one that I expect most people have already chosen their camp based > upon their personal career experiences. > I used to think that (seriously) until I realised how bad relational databases are at storing real-world models of anything but how great they are as a method of storing blobs, paths, indexable values and so on, in a totally generic way (i.e. where the schema will not change regardless of changes in the content of the data, or even its domain level information model). I believe that the textbook theory of using either E-R models or object models to represent any but the most generic things in the real world is relatively useless, for anything but a demonstration database or small, unchanging application (does such exist?). For anything real, it doesn't work because a) real-world things are almost always hierarchical compositions (due to our human way of describing them) and b) real-world things keep changing (modiyfing the schema of a database is a pain in the neck when you have 200m records and 50 tables). Using relational in the classical way works for things like tax and bank databases because the data are not 'real' things, but tabular accounting constructs.
- thomas beale
