Why have object oriented databases not been succesful (yet) ?

Question

That's the question. Give only one reason you think why have OODB failed or why many systems nowadays still use relational databases.

Answer 1

The main reason is SQL. Its very useful to be able to use data from a database in other contexts outside of the application and often with object databases the data is stored in a format that can't easily be queried. With a relational database the data can become part of a data warehouse, for instance, or just queried by sys admins etc.

Answer 2

If I can amplify Phil's point: the standardization of SQL. OODB's have tried query languages such as OQL but they never seemed to follow a true standard. Also the quality of the query languages were suspect, arguably due to lack of standardization. Standards foster competition, which spawns quality.

Answer 3

That, and o/r-mappers. Through them, the difference to true OO-DBs becomes way smaller, while the aforementioned benefits stay valid.

Answer 4

Can we answer more than once? Another reason is that relational DB's have a strong foundation in mathematics: from the definition of a relation, right through to the normal forms, the theory is rock solid. It is true that the relational model does not map well to OO, but IMHO the benefits and stability of that model outweigh the mapping problem.

Answer 5

Just because OODB are not the mainstream we should still consider the successes that they have had. Cache and Zope are both widely used (relatively) but would be considered successful by some standards.

Perhaps the biggest reason that OODB have not taken hold dramatically is because of the success of the hybrid object-relational systems that take most of the potential marketshare from OODB: PostgreSQL and Informix.

I know that this does not directly answer the question but it is, I think, part of the equation. Overall, though, I think that momentum and the heavily ingrained thought processes supporting relation databases make it difficult for people to switch. Currently the DB profession is trained almost exclusively in relational theory making your DB professionals very interested in avoiding OODB and academia teaches DB theory for practitioners almost exclusively on relational.

Until large, corporate DBAs and mainstream professors and curriculum and turning out staff beyond developers prepared to managed OODB I feel that it is unlikely to see mass appeal no matter how good it is from the development side.

Answer 6

I think it's because "object databases" are solving a problem that (almost)nobody really has. For simple persistence of object graphs, the serialization built into most OO environments is "good enough". If you want to do sophisticated operations on a subset of your data, then a relational database and SQL are a perfect fit.

Other than some fringe applications (enormous object graphs that can't be kept in memory, but for which the relationships don't simplify down well for RDBMS use), there really isn't any need for these tools.

Answer 7

RDBMs are (built on a strong theoretical foundation, have been in the market for a much longer time, can model data more faithfully than OODBs in many cases, can be used by more DBAs than OODBs). That's one reason in the form of a relational tuple.

Answer 8

I think that there are two philosophical reasons.

First, people traditionally tend to separate persistence from real functionality. Once you strip away an object's "life" away from it and keep it primarily for persistence, it becomes a record, and then there is a tendency to treat it as a "lifeless" data object.

Following on that, when people think of a large collection of very similar things, they start thinking of them as tables rather than objects.

I think with O/R the distinction is starting to disappear. For example, I use hibernate to dump really complex class hierarchies into a MySQL database. However, I don't write performance-critical stuff for my project so I'm sure it's not done efficiently.

Answer 9

+1 marxidad

Pointers are BAD in data models... OO model is very much like the old network model, which is not only proven to be inferior theoretically to the relational model, but also a pain to use in practice.

It's weird how failed data models (hierarchical -> XML, network -> OO) keep getting resurrected. To me, not learning from the past is plain silly, it looks like such a waste of precious human brain cells.

Answer 10

Well, it's strange isn't it? There is such a push towards domain driven design as the zenith of object orientated analysis and design, and there are enterprise patterns out there to leverage ORM systems to persist our objects. It just makes total sense to me that if your application DESIGN is object orientated and domain focussed at heart, that an OODB will greatly benefit your application.

Aside from the issues around maturity and uptake, from a philosophical perspective an OODB would appear beneficial or an OO application. not having to maintain that mapping layer for starters;)

But look, if you aren't doing domain drive design and use objects as data objects and like your stored procs, then you're not really going to get it;)

There are a

k

Answer 11

One reason is that databases are about data, and objects are about structures and algorithms. Once you take the data and embed it in classes, you characterize the relationships and operations in a static structure. Databases, on the other hand, are about unstructuring the data into a bunch of instances of atomic tables that can be reassembled into different structures (usually with classes) without disturbing the integrity of the atoms.

Databases are somewhat analogous to hexahexaflexagons.