Go ahead, you can do it. Login and vote now.
By e_utrilla
via lateralprogramming.wordpress.com
Published: May 07 2008 / 21:21
As mentioned in my previous post, the objective of this series of articles is to share some database design patterns that have helped me in the past to achieve, using a relational database as a backend, an reusable API for data persistence with a higher level of abstraction and flexibility, while still taking advantage of the tooling and previous knowledge of relational databases. In this second post I’ll try to cover a basic concept: the way entities are related to each other.
Comments
jtheory replied ago:
Interesting, and spot-on description of the problems of the normal relational model, but I'm not bowled over by the solution thus far. Things like this make me jumpy:
"Additional control and semantical checks can be enforced by a trigger or as part of a stored procedure used to insert the data in the physical tables. In order to keep it flexible, the valid relationships shouldn’t be hardcoded in the trigger itself, but stored in a separate metadata table."
First, "can be" -- is the author already using this model in various projects, or just inventing it now? Also, this feels like it's getting into a situation where the contortions required to make it usefully functional will be baroque enough that it's not possibly worth the pain... you know, the kind of pet project that the lead developer *before* you finally perfected after years of work... and now you have to take weeks to untangle the whole beastly clever thing before you can safely make a simple update to the database in a new feature.
I'll see what it looks like when the author gets into specifics.
Voters For This Link (12)
Voters Against This Link (0)