Op 17-02-2012 20:49, pablo pazos schreef: > the openEHR RM is an Object Oriented model, a programmer should > implement the model on the ORM tool and the schema should be generated > from those classes, in fact is the schema what accommodates to the > classes.
Starting with OpenEHR often means, For every class a table, maybe write your own access-layer, specially optimized, maybe better then hibernate, because customized. But still, to store a Locatable, with item-tree's, clusters, datavalues, it used about 40 insert-statements, (automatically generated), or more. To retrieve it, about the same number of Select-statements. Then start optimizing, and create f.e. a wide table Datavalue, which could contain a complete datavalue, so you do not any more needed to split up the datavalues. It reduces the number of SQL-statements/indexes to, maybe 25 instead of 40. Also maybe try to create a very wide table Locatable, hoping that you can do some more saving, for example, the name-attribute which is a DvText, the uid which is (mostly) a hierobjectid, you can flatten that. It helps a bit. You reduced again the number of tables/SQL/indexes, say, to 17 for a decent Locatable. I don't think that is a good way to solve this problem. There are other solutions. XML is one, but I am thinking about another way. Does someone know how an Object Database works? You offer an object, it never has seen, and it stores it. And can be queried on attribute-values. I don't know how it works, but it could be like this: I think it could work on attribute-paths. If it does, it looks like OpenEHR, which works on archetype-paths which are representations of attribute paths. Every leaf-value has a path pointing to it. Every locatable has a UID. These both make every single leaf value unique. Imagine: When splitting the data over tables, your query engine needs to use more then one SQL statement, or join several statements, needs to open indexes, needs to read key-fields and jump to them in indexes, and so on and on. Every table/class involves costs. The more complicated an Locatable-object is, the more expensive it is to store. It is also possible to flatten the whole business to one table. Only one simple query retrieves a complete locatable. Only one index used. Also, implementing AQL is not very hard, the necessary information is indexed available. That must be very very fast. I don't think, faster is possible. Only 1 SQL statement to retrieve all values of a Locatable. And there is no problem with the large number of records that table has, and there is no scaling problem. Every record is, in fact, one leaf value. The rumor says Postgres is fastest (I heard, Oracle has a problem admitting this) until 100 million records, after that one should start thinking about NOSQL-solutions. 100 million records mean about 25.000 average patients. 4000 datavalues for one average patient. The older versions of Locatables, they of course go to a separate table. Some NOSQL-databases have a versioning system themself. But there are some disadvantages. you must create RM-instances from path-notations, you must keep pointers to parents, the software logic is more complicated then dumping it to hibernate or XML. But this to solve, not really rocket science, and because the kernel is stable the code last a long time. And even when the RM-specs change, without migrating, It can support more versions of the RM-model in one table, simultaneous. Think about it. I did think about that, the kernel-speed improved with a factor 50. I saw, some month ago, a person, technician who wrote an SQL engine for a HL7 RIM database. The engine created SQL statements to retrieve values. I cannot remember the exact numbers, but I thought, 200 tables were involved, and the SQL statement (automatically generated) was about 100 lines at least. It is easy for programmers, it develops quick and without errors, but is it good? I think speed and simplicity is necessary for success. Speed because of the simple table design and short SQL statements, simplicity because of the archetypes, not software, defining the job. regards Bert Verhees
