>Regarding "content structures", these could be persisted as "objects" in ad hoc field in the database.
What kind of "objects"? And how would any approach of this sort be much better than XML? You'd still have to retrieve, parse or otherwise deserialize the entire blob before you could productively read, or navigate to, the tiniest part of it, taking time and resources. And it would seem that your object would have to be mixed with a lot of instance-level metadata (as in XML), further bloating its size, complexity and internal overhead. And are there non-proprietary ways to do this? I never mentioned blobs. Precisely.XML structures would be one of the best choices (or probably better: a JSON "object"). If you read on you'll see that that is precisely what I did in the past. That is why I enclosed the word object with double quotes (meaning to use the concept metaphorically). Serializing (real) runtime objects into XML or JSON "objects" and storing these "complex data types" (I should probably have used this terminology) is, to the best of my understanding, the most convenient choice. So I fully agree with your comments. I don't see how the functionality of such objects would greatly exceed that of a PDF text document (possibly including a document-level table of contents), which, at the end of the day, is what a lot of EMR systems essentially amount to. Doctors typically pull up text-based notes often autogenerated from discrete fields never searched upon again and which may even die upon the generation of the note. I understand that one approach is to provide some basic indexed "pointers" to the blob within the DB, but that does not really overcome the basic problem that blobs pose. Sure. Blobs are ghastly and under no circumstance would I propose their use for storing information of the type we are dealing with here. One could argue that this at least avoids the problems often associated with EAV, but at the expense of easy and efficient access to discrete data elements. If a weight is too heavy to lift one solution is simply not to lift it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110607/dcae2b9d/attachment.html>
