3 ms·

Objects should be an abstraction layer between atomic data and the user, but data should always be stored atomically in a relational model.

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 ago
  Not 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 ago
  I 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.
slpsys 18y ago
Objects should definitely just be an abstraction of the data, but I'm not sure where your specific requirement for a relational model comes from.
- TweedHeads 18y ago
  Codd did his job very well when he set the model 40 years ago based on set theory and predicate logic. It has to do with atomicity, redundancy, validity and integrity of data. Any object you can imagine can be decomposed in atomic parts that can be stored individually with their respective relations to each other.
  - jrockway 18y ago
    Any object you can imagine can be decomposed in atomic parts that can be stored individually with their respective relations to each other. Uh, yes? What makes you think that this isn't how an OODB works? Generally, each object is stored as a graph of its dependencies. (A class has attributes, and an instance of a class is a collection of instances representing these attributes. This is what's stored in the database... and in memory, for that matter.) Codd did his job very well when he set the model 40 years ago based on set theory and predicate logic. It has to do with atomicity, redundancy, validity and integrity of data. Care to go into more detail here? Nothing you say has much to do with object databases -- they can be fully ACID, they store objects that are the same in memory as the same object in the database, and they don't magically make a consistent memory image inconsistent. As long as your in-memory data makes sense, the data in your object database will make sense. If your in-memory data doesn't make sense, then who cares what's stored? You corrupted your data a long time ago, and no set theory is going to fix that.
jrockway 18y ago
Why? So you can write more code, and hack around the O/R impedance mismatch? If objects are what your application code interacts with, why would you want to translate them to an unrelated form just to store them on disk?
- TweedHeads 18y ago
  Do you know how many entities form an invoice? Do you know what happens if one those entities change, like a phone number, a vendor's email or a product packaging? Instead of updating one entity, you will need to update every single object that contains the wrong data. How do you maintain integrity if redundancy is part of your model?
  - jrockway 18y ago
    Instead of updating one entity, you will need to update every single object that contains the wrong data. No, this is not true. Your invoice has a reference to the vendor. If you update that vendor object, when you request the invoice, you'll get the updated vendor object. Your complaint describes problems associated with document databases. Document databases are not object databases. (For example, CouchDB is a document database, not an object database. So if you hate CouchDB, you might not hate object databases.)
    - TweedHeads 18y ago
      "Your invoice has a reference to the vendor." Relational model. Case closed.
      - jrockway 18y ago
        You do know that the "relational" model refers to relations, not relationships, right?

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 ago
Not 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 ago
I 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.

slpsys 18y ago

Objects should definitely just be an abstraction of the data, but I'm not sure where your specific requirement for a relational model comes from.

TweedHeads 18y ago
Codd did his job very well when he set the model 40 years ago based on set theory and predicate logic. It has to do with atomicity, redundancy, validity and integrity of data. Any object you can imagine can be decomposed in atomic parts that can be stored individually with their respective relations to each other.
- jrockway 18y ago
  Any object you can imagine can be decomposed in atomic parts that can be stored individually with their respective relations to each other. Uh, yes? What makes you think that this isn't how an OODB works? Generally, each object is stored as a graph of its dependencies. (A class has attributes, and an instance of a class is a collection of instances representing these attributes. This is what's stored in the database... and in memory, for that matter.) Codd did his job very well when he set the model 40 years ago based on set theory and predicate logic. It has to do with atomicity, redundancy, validity and integrity of data. Care to go into more detail here? Nothing you say has much to do with object databases -- they can be fully ACID, they store objects that are the same in memory as the same object in the database, and they don't magically make a consistent memory image inconsistent. As long as your in-memory data makes sense, the data in your object database will make sense. If your in-memory data doesn't make sense, then who cares what's stored? You corrupted your data a long time ago, and no set theory is going to fix that.

jrockway 18y ago

Why? So you can write more code, and hack around the O/R impedance mismatch? If objects are what your application code interacts with, why would you want to translate them to an unrelated form just to store them on disk?

TweedHeads 18y ago
Do you know how many entities form an invoice? Do you know what happens if one those entities change, like a phone number, a vendor's email or a product packaging? Instead of updating one entity, you will need to update every single object that contains the wrong data. How do you maintain integrity if redundancy is part of your model?
- jrockway 18y ago
  Instead of updating one entity, you will need to update every single object that contains the wrong data. No, this is not true. Your invoice has a reference to the vendor. If you update that vendor object, when you request the invoice, you'll get the updated vendor object. Your complaint describes problems associated with document databases. Document databases are not object databases. (For example, CouchDB is a document database, not an object database. So if you hate CouchDB, you might not hate object databases.)
  - TweedHeads 18y ago
    "Your invoice has a reference to the vendor." Relational model. Case closed.
    - jrockway 18y ago
      You do know that the "relational" model refers to relations, not relationships, right?