I have not performance tested my own implementation (although I did
actually build one over a decade ago). But the Informix path system was
real and performant (they used a hierachical number node code approach
e.g. 1.2.3, 1.2.3.1.2 etc). There are others I have read about as well,
but I'd have to spend a bit of time to track them down, not having
looked at it for a few years.
The reason why it can be fast is that you don't have many columns and
essentially no joins, and you can do extremely efficient matching on
number spaces to determine the 'type' of something (i.e. whether it is a
systolic BP or whatever) /before/ you decompress the value (a
DV_QUANTITY). Then you do value comparison (e.g. bp > 160 or whatever)
as a second step.
Before doing any of this, you apply basic AQL logic that cuts out whole
parts of the DB because their values are not inside (AQL CONTAINS; XML
'//') the required kind of Composition.
If you have run an actual study of path-based performance and found it
not to be working, it would be very interesting to know the details. It
may be that with some adjustments you can significantly change the
performance characteristic.
- thomas
On 26/01/2016 10:43, Jan-Marc Verlinden wrote:
Hi Thomas,
/_this is also what I would expect. Path-based storage does rely on
very smart ways to figure match terms in a query to paths of course._/
Did you test, or is this theoretical?
Jan-Marc
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
