

Object-Oriented Database Management Systems Succeeded - neilc
http://danweinreb.org/blog/object-oriented-database-management-systems-succeeded

======
trjordan
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
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.

------
kingkongrevenge
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
_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
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
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
_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
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
_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
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.

~~~
neilc
Complex business logic constraints depend on "the object model and
polymorphism"? Can you give an example?

~~~
gnaritas
Objects can validate themselves and object databases store the class as well
as the instances. This allows a database to contain a mix of different
versions of a particular class of objects. The invoice from yesterday might
have 5 fields and validate under one set of rules while todays invoice has 7
fields and validates itself under a completely different set of rules.

Such polymorphism is trivial to implement with objects and very painful to
implement withing a relational database. It's not a matter of whether a RDBMS
_can_ model something, it's a matter of how much effort is required.

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

~~~
silentbicycle
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>

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

