Heath, Good clear answer. Thanks.
You enable me to take us back to where this conversation started. I can now make a possibly uneducated guess how the Ocean querying works: You parse AQL queries into two distinct parts, (1) for the relational DB and its paths and (2) for the "object layer." The first part narrows down the range of blobs you must look at as far as possible, and the second part penetrates into specific values in the blobs themselves. If you end up with 10,000 blobs resulting from part 1, you must parse and instantiate each one into the memory of your object server and then step through each one to find which of them satisfies the query. If I'm right, your system could run reasonably fast if part 1 of the query does not not yield a large result or if your object server runs on some heavy iron. I'm not sure if one of your blobs represents one complete patient record or merely a fragment of the record, but if it does encompass the complete record, the blob size could be large and the instantiation process (involving parsing if XML) in itself would consume resources and take time. Maybe you've found that querying against a large set of blobs is seldom necessary. There are tradeoffs no matter how one goes, and I can see your logic. You mention the need for (1) obfuscation and (2) semantic integrity. Thomas's concern centered more on the complexities of expressing hierarchies in traditional relational terms, and in maintaining ever-changing models (see his extended comment in this thread). Either way, you end up with your chosen architecture. Did Ocean consider, at the beginning, using a relational node-based graph (verticies, edges, etc) structure, without blobs and without the schema itself ever having to change, and reject the idea? Best regards, Randolph On 11/7/07, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > > Randy, > > We have already indicated that we store indexed blobs. We can store these > blobs as XML, DADL or Binary. It doesn't matter, it is just a serialisation > format and the "MAGIC" happens in the object layer. Another benefit of this > is that it obfuscates the EHR content forcing the data access through the > EHR Server to ensure that the semantics and security of the content is > maintained. This is a deterrent to traditional application developers > bypassing these important EHR requirements. > > > > Regards > > > > Heath > > > > Heath Frankel > Product Development Manager > > Ocean Informatics > > Ground Floor, 64 Hindmarsh Square > > Adelaide, SA, 5000 > > Australia > > > > ph: +61 (0)8 8223 3075 > > mb: +61 (0)412 030 741 > email: heath.frankel at oceaninformatics.com<heath.frankel at > oceaninformatics.biz> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/c9a7a48b/attachment.html>
