6 ms·

Object-Oriented Database Management Systems Succeeded

15 points by neilc 18y ago

kingkongrevenge 18y ago
We use object store for exactly the kind of thing he argues it should be used for (slightly analogous to CAD). I think it sucks. A normalized relational schema would be much better. Instead we suffer endless invalid pointer crashes and inconsistent data all over the place. Changing the schema is also a nightmare. OODBs are a seductive hack. They can look like a great idea because initial development is simple. You get to skip the laborious step of developing a proper relational schema and setting up mechanisms to ensure integrity. Two years later your data is an inflexible mess with subtle integrity errors here and there.
- jrockway 18y ago
  Two years later your data is an inflexible mess with subtle integrity errors here and there. Well yeah, if you do it wrong, it doesn't work. You get to skip the laborious step of developing a proper relational schema and setting up mechanisms to ensure integrity. Basically, every program needs to ensure consistency of its in-memory structures. If you have invalid data in memory, you can't trust your program to return correct results. With an OODB, you reuse these integrity checks for your data model. With a relational database, you have to specify your constraints a second time. Twice as much code == twice as many bugs.
  - kingkongrevenge 18y ago
    Tons of first hand experience and expert research says that relational normalization is the best way to avoid mistakes. > If your in-memory data doesn't make sense, then who cares what's stored? You are going to screw up your in memory data structures in a complex application. It WILL happen. A normalized relational schema will catch the mistake. You can go 3NF, with decades of experience and theory. Or you can wave your hands and say "don't make mistakes" in your hierarchical/oodb system. If you need simple persistence for an app that will be dead inside a few years, go knock yourself out with an OODB. It will work fine. If you're doing something complex, like say the equivalent relational DB would have a few dozen tables, I think it's foolish. You really probably aren't smarter than the collective experience that has successfully settled on the relational model.
    - jules 18y ago
      In my experience, keeping objects consistent is easier than keeping the database consistent. The database can only do trivial consistency checks. With objects you can write arbitrary predicates that check things about your objects. In the applications I write that means that even though I use a relational database, I end up doing all important checks on the objects, and none in the DB.
      - neilc 18y ago
        The database can only do trivial consistency checks. Between foreign keys, triggers, and CHECK constraints, databases can actually do pretty sophisticated consistency checks. There's also a SQL standard feature for database-wide assertions that would be very useful, but AFAIK no one implements it (probably for performance reasons).
        gnaritas 18y ago
        Actually, no, it can't, unless you code all your business rules into the db as well. The advantage the objects have is that they're also the application and all the rules are there and checkable.
        neilc 18y ago
        Actually, no, it can't, unless you code all your business rules into the db as well. Well, you can code all your business rules into the DB, in the form of stored procedures. But even if you choose not to, I don't see why that fact prevents you from enforcing a wide range of consistency constraints in the database.
        gnaritas 18y ago
        I didn't say you can't do any checks, rather, the db does mostly simple checks. The complex checks often depend heavily upon the object model and use of features like polymorphism which relational databases suck at modeling.
- jules 18y ago
  Do you think this is a feature of the particular OODB you're using, or of OODBs in general? Do you think your problems can be solved by changing the OODB (adding a static type system, for example).
  - kingkongrevenge 18y ago
    Of course the commercial oodbs are statically typed. I'm not sure what you're getting at. OODBs are fundamentally flawed in the way you have to manage pointers between objects. You also inevitably wind up with copied data.
    - jrockway 18y ago
      As I state in another thread, you are thinking of document databases, not object databases. If you have two copies of the same piece of data, you're misusing the database. I'm also not sure what problem pointers are. They work fine for in-memory data, why would they not work for persistent data?
      - kingkongrevenge 18y ago
        Complex in memory object graphs do not work fine. Programmers inevitably screw up. In complex systems you also inevitably get denormalized copies of objects in an OODB. You're not saying anything that's incorrect. It's true, anything you can do with a relational db you can theoretically do with an OODB. In many cases you likely will finish with less code. However, this theoretical fact flies in the face of a lot of experience that indicates the superiority of the relational model.
        jrockway 18y ago
        The relational model doesn't prevent programmer fuckups, nor does it save them from many common errors. For example: sub add_one_to_each_row { my $row = shift; $row->some_relevant_column( $row->some_relevant_column - 1 ); $row->update; } Although the data is fully relational, your program corrupted it anyway. (As a slightly-related aside, I really need to write an essay about how type systems don't prevent bugs when you use overly-broad types like "Integer".)
TweedHeads 18y ago
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
trjordan 18y ago
Can somebody explain to me the difference between using an OODB to back your web app and using a web framework like Rails or Django?I know the actual implementation is different, but the abstraction presented seems to be the same...
- jrockway 18y ago
  There isn't much difference if you only work with single elements and sets of single elements. (Imagine, a user with a username and password; and the set of all users.) Things become more complex when you want to store arbitrary data structures. A simple example is a doubly-linked list. This is easy to represent in memory, and it's easy to represent in a relational database, but it's not particularly easy to translate between the two representations. With an object database, the in-memory structure is the persistent structure, so there is no translation. Anything you have in memory can be put in the database. (Most implementations let you index and query this data, as well, and provide you with opportunities to create indexes that would be difficult or impossible to represent with a relational database management system.) Also, a key feature of OOP is polymorphism, which the relational model does not handle elegantly. Object databases handle it fine.

15 points by neilc 18y ago

We use object store for exactly the kind of thing he argues it should be used for (slightly analogous to CAD). I think it sucks. A normalized relational schema would be much better. Instead we suffer endless invalid pointer crashes and inconsistent data all over the place. Changing the schema is also a nightmare. OODBs are a seductive hack. They can look like a great idea because initial development is simple. You get to skip the laborious step of developing a proper relational schema and setting up mechanisms to ensure integrity. Two years later your data is an inflexible mess with subtle integrity errors here and there.

jrockway 18y ago
Two years later your data is an inflexible mess with subtle integrity errors here and there. Well yeah, if you do it wrong, it doesn't work. You get to skip the laborious step of developing a proper relational schema and setting up mechanisms to ensure integrity. Basically, every program needs to ensure consistency of its in-memory structures. If you have invalid data in memory, you can't trust your program to return correct results. With an OODB, you reuse these integrity checks for your data model. With a relational database, you have to specify your constraints a second time. Twice as much code == twice as many bugs.
- kingkongrevenge 18y ago
  Tons of first hand experience and expert research says that relational normalization is the best way to avoid mistakes. > If your in-memory data doesn't make sense, then who cares what's stored? You are going to screw up your in memory data structures in a complex application. It WILL happen. A normalized relational schema will catch the mistake. You can go 3NF, with decades of experience and theory. Or you can wave your hands and say "don't make mistakes" in your hierarchical/oodb system. If you need simple persistence for an app that will be dead inside a few years, go knock yourself out with an OODB. It will work fine. If you're doing something complex, like say the equivalent relational DB would have a few dozen tables, I think it's foolish. You really probably aren't smarter than the collective experience that has successfully settled on the relational model.
  - jules 18y ago
    In my experience, keeping objects consistent is easier than keeping the database consistent. The database can only do trivial consistency checks. With objects you can write arbitrary predicates that check things about your objects. In the applications I write that means that even though I use a relational database, I end up doing all important checks on the objects, and none in the DB.
    - neilc 18y ago
      The database can only do trivial consistency checks. Between foreign keys, triggers, and CHECK constraints, databases can actually do pretty sophisticated consistency checks. There's also a SQL standard feature for database-wide assertions that would be very useful, but AFAIK no one implements it (probably for performance reasons).
      - gnaritas 18y ago
        Actually, no, it can't, unless you code all your business rules into the db as well. The advantage the objects have is that they're also the application and all the rules are there and checkable.
        neilc 18y ago
        Actually, no, it can't, unless you code all your business rules into the db as well. Well, you can code all your business rules into the DB, in the form of stored procedures. But even if you choose not to, I don't see why that fact prevents you from enforcing a wide range of consistency constraints in the database.
        gnaritas 18y ago
        I didn't say you can't do any checks, rather, the db does mostly simple checks. The complex checks often depend heavily upon the object model and use of features like polymorphism which relational databases suck at modeling.
jules 18y ago
Do you think this is a feature of the particular OODB you're using, or of OODBs in general? Do you think your problems can be solved by changing the OODB (adding a static type system, for example).
- kingkongrevenge 18y ago
  Of course the commercial oodbs are statically typed. I'm not sure what you're getting at. OODBs are fundamentally flawed in the way you have to manage pointers between objects. You also inevitably wind up with copied data.
  - jrockway 18y ago
    As I state in another thread, you are thinking of document databases, not object databases. If you have two copies of the same piece of data, you're misusing the database. I'm also not sure what problem pointers are. They work fine for in-memory data, why would they not work for persistent data?
    - kingkongrevenge 18y ago
      Complex in memory object graphs do not work fine. Programmers inevitably screw up. In complex systems you also inevitably get denormalized copies of objects in an OODB. You're not saying anything that's incorrect. It's true, anything you can do with a relational db you can theoretically do with an OODB. In many cases you likely will finish with less code. However, this theoretical fact flies in the face of a lot of experience that indicates the superiority of the relational model.
      - jrockway 18y ago
        The relational model doesn't prevent programmer fuckups, nor does it save them from many common errors. For example: sub add_one_to_each_row { my $row = shift; $row->some_relevant_column( $row->some_relevant_column - 1 ); $row->update; } Although the data is fully relational, your program corrupted it anyway. (As a slightly-related aside, I really need to write an essay about how type systems don't prevent bugs when you use overly-broad types like "Integer".)

TweedHeads 18y ago

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

trjordan 18y ago

Can somebody explain to me the difference between using an OODB to back your web app and using a web framework like Rails or Django?I know the actual implementation is different, but the abstraction presented seems to be the same...

jrockway 18y ago
There isn't much difference if you only work with single elements and sets of single elements. (Imagine, a user with a username and password; and the set of all users.) Things become more complex when you want to store arbitrary data structures. A simple example is a doubly-linked list. This is easy to represent in memory, and it's easy to represent in a relational database, but it's not particularly easy to translate between the two representations. With an object database, the in-memory structure is the persistent structure, so there is no translation. Anything you have in memory can be put in the database. (Most implementations let you index and query this data, as well, and provide you with opportunities to create indexes that would be difficult or impossible to represent with a relational database management system.) Also, a key feature of OOP is polymorphism, which the relational model does not handle elegantly. Object databases handle it fine.