Joins can cost you a lot, depending on how you slice and dice, yah? And how much normalization. And especially if you have hierarchical data, which the relational model isn't too good at.
Agreed. The relational model has stood the test of time because of its flexibility. When you start adding methods to data, i.e. create objects, you start to dictate the structure of data. This is good for applications, but not so good for shared data stores. The relational model allows you to store the data in a far more application-neutral manner than you can with OO structures. You can more easily reanimate the data in whatever manner you please (though it may cost you). That means more sharing, ironically, which is one of OOP/D's main draw.
You've got pretty much too choices in object-relational mapping: write a custom mapper or suck wind with a framework. Hopefully we'll find some better options soon.
Slashdot Mirror
Joins can cost you a lot, depending on how you slice and dice, yah? And how much normalization. And especially if you have hierarchical data, which the relational model isn't too good at.
Agreed. The relational model has stood the test of time because of its flexibility. When you start adding methods to data, i.e. create objects, you start to dictate the structure of data. This is good for applications, but not so good for shared data stores. The relational model allows you to store the data in a far more application-neutral manner than you can with OO structures. You can more easily reanimate the data in whatever manner you please (though it may cost you). That means more sharing, ironically, which is one of OOP/D's main draw. You've got pretty much too choices in object-relational mapping: write a custom mapper or suck wind with a framework. Hopefully we'll find some better options soon.