5 ms·
OODBs sound like a great idea in theory, but I've yet to meet a good OODB in practice. Just use an RDBMS and in your application use a layer which abstracts aw
by jey 19y ago
OODBs sound like a great idea in theory, but I've yet to meet a good OODB in practice.
Just use an RDBMS and in your application use a layer which abstracts away the "relational" part of the RDBMS and exposes it as objects to the rest of the application. This /can/ get a bit tricky with transactions and etc, but your internal data layer can be designed with some notion of transactions.
- avibryant 19y agoAbstracting away the "relational" part of the RDBMS sounds like a great idea in theory, but I've yet to meet a good O/R mapping layer in practice. What I have met is several IT projects that have failed thanks to inordinate amounts of resources sunk into O/R mapping issues...
- corentin 19y ago> Abstracting away the "relational" part of the RDBMS sounds like a great idea in theory [...] Abstracting away a model doesn't sound like a great idea to me.
- jey 19y agoEver programmed in a "Higher Level Language"? The model of register-based computation has been abstracted away! Seems OK to me.
- jey 19y agoObject Orientation shouldn't be treated as a religion to which you must strictly adhere. You just want some useful concepts and abstractions to express your code in terms of. I don't want to see "LEFT OUTER JOIN" sprinkled through my code, as that's not a concept that is relevant to my application logic. Nor do I want to spend months implementing some idiotic "Object Oriented Design Patterns" because it's the current fad to join the Church of Object Orientation. I just aim to have some nice, clean concepts with which I can write simple and elegant code.