Why have object oriented databases not been successful (yet)? [closed]

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

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 2

The main reason is SQL. It is very useful to be able to use the 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 3

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 4

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 5

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;)

Answer 6

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 7

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 8

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.

Answer 9

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

Answer 10

Expensive technology decisions are not made by people with technical knowledge. Companies using relational databases employ lots of people who feel threatened by OODBs and therefore will avoid learning about them.

Answer 11

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 12

The reason for the slow adoption of OODB's are based largely on a few key factors that make the relational SQL databases more popular and/or more appropriate. While pure object-oriented databases are now in a state where they overcome much of the drawbacks of the relational model, there are some key pieces missing.

For one they tend to lack support for central database management, though this is rapidly being rectified in various products.

A second reason is that very few systems implement a standard query language and instead relies on the programming language or specialized query languages to retrieve and manipulate the data in store. This is a show stopper for many if they have to learn a new query language on top of the totally different mindset of a programmer used to NoSQL based solutions. On top of that, most SQL based / Relational databases now have some support for Object Oriented Design, plus we have wrappers like ORM that many use to "bypass" the problems of relational databases not being readily available in the programming language of choice.

But these problems exist mostly in corporate environments. As embedded databases in small devices, as web site storage and in fields like aerospace they have become very popular and in many cases totally replaced the need for regular relational databases.

Who knows what the future holds?

Answer 13

Serialization provided by the most of Language lets you flaten the Object attributes and thus storing easily them into the RDBMS and similarly retrieving objects is not a big issue. The wide and solid foundation still lacks which hinders the use of OODBMS to be implemented.

I currently thinking of doing this as my Master Thesis project to provide a general framework for OODBMS that supports almost all the components which is commonly used in now a day RDBMS thus providing a non-linear structured DBMS. While studying I came across a project called db4o which is an approach (implemented) of using OODBMS for Java and .net only, so this could be another reason of lack of generality for all types of platforms and languages.

Answer 14

I think that's because big guys like Oracle had been investing in relational databases while object oriented movement was getting momentum...may be they will become mainstream if Oracle / Microsoft invest in it in a big way...which seems unlikely because they don't have a strong reason to do so...it will simplify lives of many programmers...but "making programmers lives simpler" is not a very good business goal for them!