> Thomas, thanks for your extended remarks. Your point is one you've made for > a long time, that relational db schemas cannot keep up with the real world. > I'm just wondering if moving the problem out of the relational DB and into > blobs (persisted objects, I take it) solves the problem you so eloquently > depict. Yes, it solves the schema problem. I grant you that. But you're
Well it does more than that - it allows the databse to be used to perform optimised querying for a certain category of data (e.g. archetyped, blobbed data), rather than for particular content (e.g. path results versus patient details). > still left with imperfect and changing models even with blobs. imperfect in what sense? I've read the > openEHR specs enough to know that when an archetype version changes, one is > obliged to convert all existing records (blobs) to conform to the new > version, and that, it seems, would not be trivial. That task would worry Not, not at all. Archetypes are immutable, and the data always conform to thesame archetype. A new 'version' is in fact a new archetype which just happens to have a similar name. New versions are not made very often, because built-in flexibility (see e.g. generic archetypes like the lab archetype) new revisions (compatible changes) and specialisations are used to deal with almost all new requirements relating to existing archetypes. If a new version becomes necessary, it is a new archetype. Data created with the previous version still conform to that previous version, which is always available in the repository. The data could be migrated to conform to the new version, but this is only sensible if it is a useful thing to do. The main thing to understand is that new 'versions' are not the main way of dealing with changing requirements in archetypes. > me. Every affected blob would have to be rewritten. Maybe the only real > problem you're even trying to solve is that of the relational schema. You > allow that there are many ways other than the path-blob approach, but you've > made it clear that your preference is definitely that, another indication of > how intractable the root problem actually is. You could just as easily use an object database. We have for example used Matisse on other projects - it is an excellent product, and allows object data to be correctly represented in a language independent way (unlike VM-style caches like db4o). It could be used perfectly well with openEHR. - thomas
