3 ms·
The problem is that, in practice, these often work against each other. OO-style abstractions and relational schema design can pull developers in very different
by silentbicycle 18y ago
The problem is that, in practice, these often work against each other. OO-style abstractions and relational schema design can pull developers in very different directions. See, for instance: http://c2.com/cgi/wiki?ObjectRelationalImpedanceMismatch http://c2.com/cgi/wiki?ObjectRelationalImpedanceMismatch
Also, I suspect the set of programmers that understand how to do OO design well AND have a solid understanding of relational databases is relatively small.
(edited to flesh out a bit)
- TweedHeads 18y agoNot necessarily, but I get your point. When I say Invoice.Select(1234) I want the data engine to query 20 nicely normalized tables and bring me back one object with the invoice I am looking for. The same when I say Invoice.Update() Most DBAs are very jealous of their territory and rarely collaborate with programmers in how to make that process transparent to both of them.
- TweedHeads 18y agoI see your point. OO programmers who don't understand the relational model want to 'force' the database to deal with objects and there the impedance mismatch. In that case Relational Objects Database might be a better model. Let the database store the whole object as an entity, an as the system evolves it can be 'normalized' to more atomic sub-objects giving the programmer time to grasp the relational model. For simple systems like a contact list, a contact object would suffice, even if it has many phones or many addresses. Get one contact, put one contact. The more complex it evolves the need to change the schema to make it easier to maintain and to avoid redundancy while keeping data integrity. In the end, a complex system would deconstruct complex objects into simple atomic objects (data) related to each other with simple rules.