4 ms·

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 schem

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".)

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".)