Seref, I was simply trying to take your hint. :).
On Wed, Apr 17, 2013 at 5:08 PM, Seref Arikan < serefarikan at kurumsalteknoloji.com> wrote: > AQL is not part of the official specification yet. > > Regards > Seref > > > > On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall < > randy.neall at veriquant.com> wrote: > >> Thomas, somehow I'm not finding the AQL specification. It's probably >> right under my nose on your specification/release page. Also, do you have >> any references describing the AQL processor? Did you write *that* from >> scratch?? It would seem that the AQL processor would indeed function as >> a formidable DBMS in its own right, at least with regard to reads, capable >> of managing AND/OR logic trees and serving up flat "tables" of joined data >> structures like any RDBMS. >> >> Randy >> >> >> On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale < >> thomas.beale at oceaninformatics.com> wrote: >> >>> On 17/04/2013 18:47, Randolph Neall wrote: >>> >>> >The performance is perfectly adequate in all of these systems for the >>> kinds of queries used in point of care (e.g. typically sub 1-second), and >>> in some cases where ETL is implemented, the performance is also acceptable. >>> It's also true that quite a lot of effort and thinking has gone into >>> optimising AQL queries. There is always a query that can be written that >>> will take a long time to answer, but so far there is no overlap between >>> those type of queries and point of care latency requirements i.e. such >>> queries are always report-oriented, research queries or some other kind of >>> population query, where a (let's say) 5 second response is perfectly >>> acceptable. >>> >>> That's excellent! Can you give any idea how long it takes to retrieve >>> into live memory and screen on a user's computer an entire EHR record of >>> "typical" size and complexity? Or does that not generally happen, with >>> records instead being fetched in smaller pieces? >>> >>> >>> Right - you wouldn't ever pull an entire EHR to the screen. I have seen >>> openEHR applications pulling the main managed lists (say 6-8 Compositions), >>> latest lab results, plus a chronological list of consultations / events for >>> the last year or so, plus key demographic data, all sub 0.5 sec. Then the >>> user starts clicking on things, and more comes back. >>> >>> More interesting screens contain a mixture of text and e.g. vital signs >>> real-time graphs, which AQL copes with nicely - you can bring back just a >>> 2-D array of numbers and timestamps for the graph, using AQL. >>> >>> - thomas >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/da261169/attachment.html>
