They can answer that but for your info I considered it and accepted it :-). Which brings me to the next question but I will start a new thread.
On 11/8/07, Randolph Neall <randy.neall at veriquant.com> wrote: > 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> > > > > > > >
