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 |
||
| (42 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 8: | Line 12: | ||
== The basic Meta Model == |
== The basic Meta Model == |
||
This chapter will describe a generic meta model for object orientated systems. |
This chapter will describe a generic meta model for object orientated systems. The following class diagrams are designed with mapping to database tables in mind. Therefore the direction of the association arrows may appear strange on a first glance. |
||
=== Model Layer === |
=== Model Layer === |
||
| 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]] }} |
|||