4 ms·

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 pointer

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".)
    - kingkongrevenge 18y ago
      That's not a relevant example.
      - jrockway 18y ago
        The point is, at some point your application can touch the data, and a bug in the application can easily ruin it... regardless of the underlying database topology. Additionally, it's easier to create rich type constraints in object systems than it is in SQL. (Note: Java and C++ do not count as OO languages. They are missing too many features.)
jules 18y ago
I was thinking about a type system that forces all pointers to be non-null, with a Maybe/Option type for optional 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".)
  - kingkongrevenge 18y ago
    That's not a relevant example.
    - jrockway 18y ago
      The point is, at some point your application can touch the data, and a bug in the application can easily ruin it... regardless of the underlying database topology. Additionally, it's easier to create rich type constraints in object systems than it is in SQL. (Note: Java and C++ do not count as OO languages. They are missing too many features.)

jules 18y ago

I was thinking about a type system that forces all pointers to be non-null, with a Maybe/Option type for optional data.