Meta object model for relational data storage: Difference between revisions

Jump to navigation Jump to search
Content deleted Content added
imported>Hendrik Brummermann
imported>Hendrik Brummermann
No edit summary
 
(36 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Navigation for Marauroa Top|Internals}}
This article describes the idea of use a meta model to store RPClasses and RPObjects. It is not planned to actually do this anytime soon.
{{Navigation for Marauroa Developers}}


{{Future Concept}}




Line 30: Line 34:


== Converting the Meta Model into a database structure ==
== Converting the Meta Model into a database structure ==

TODO: ...

== Performance optimization for inheritance ==

TODO: reflexive and transitive

== Version support for the model layer ==

TODO: ...

== Revision support for the instance layer ==

TODO: ...

== TODO ==


TODO: ...
TODO: ...
Line 61: Line 81:
This basic model can than be easily extended. For example in our case we want a sort order in links table. And because some databases are very slow at deleting rows, or just in case we may want a revision safe system there is an easy way to achieve that: Add a new table activity which basically has a timestamp. All the table on the instance layer get two additional columns: created_activity_id and deleted_activity_id. This is a lit bit redundant but required for performance reasons. Together with a second trick, the whole system is much faster as one would guess: This trick is to have two special activities: "beginning of time" (lowest possible date) and "end of time" (highest possible date). This allows to greatly simplify the queries, because deleted_activity now always has a valid value. Life objects are simply deleted at the end of time.
This basic model can than be easily extended. For example in our case we want a sort order in links table. And because some databases are very slow at deleting rows, or just in case we may want a revision safe system there is an easy way to achieve that: Add a new table activity which basically has a timestamp. All the table on the instance layer get two additional columns: created_activity_id and deleted_activity_id. This is a lit bit redundant but required for performance reasons. Together with a second trick, the whole system is much faster as one would guess: This trick is to have two special activities: "beginning of time" (lowest possible date) and "end of time" (highest possible date). This allows to greatly simplify the queries, because deleted_activity now always has a valid value. Life objects are simply deleted at the end of time.

[[Category:Marauroa]]
{{#breadcrumbs: [[Marauroa]] | [[Navigation for Marauroa Developers|Internals]] | [[Marauroa Roadmap|Roadmap]] | [[Meta object model for relational data storage|Meta object model]] }}