Why did object oriented databases fail? [closed]

Answer 1

Because, as much as ODBMS advertisements were laden with derogatory language about ORM systems, it wasn't that hard to make ORMs do the job, and without all the various hits taken in switching to a pure ODBMS.

What actually happened is that your first code sample won, it just happens to be on a RDBMS persistence layer.

Answer 2

I think a lot of your answer lies in the "Why we abandoned Object Databases" answer of "Object Oriented vs Relational Databases".

As far as your example goes, it doesn't have to be that way. Linq to SQL is actually a quite nice basic layer over a DBMS, and Linq to Entities (v2 -- v1 sucked) will be pretty cool too. (N)Hibernate has been solving the problem you're having for years now using RDBMSes.

So I guess my answer to you is that O/R mappers are getting to the point where they solve your problem nicely, and you don't need an ODBMS to get what you need.

Answer 3

I have been using db4o (an object oriented database) lately on my personal pet projects, just because it is so quick to set up & get going. No need with the itty, gritty details.

That aside, as I see it, the main reasons why they haven't become popular are:

• Reporting is more difficult on object oriented databases. Related to this, it is also easier to manually look into the actual data in a relational database.
• Microsoft and Oracle base so much of their business on relational databases.
• Lots of businesses already have relational databases in place.
• The IT departments often have relational database expertise.

And, as Jan Aagaard, have pointed out, lately it is because the problem have been solved in a different way, giving programmers the object oriented feel even though they program against a relational database.

Answer 4

First, I don't believe they have "failed" entirely. There are still some around, and they're still used by a couple of companies, as far as I know.

anyway, probably because a lot of the data we want to store in a database is relational in nature. The problem is that while yes, OO databases are easier to integrate into OO programming languages, relational databases make it easier to define queries and, well, relations between the data stored. Which is often the complicated part.

Answer 5

They will succeed some day. They are future.

Looking back to software technologies in history, the trend is sacrificing performance to reduce complexity (Assembly => C => C++ => .NET). An application which takes 30 minutes to code now, some days in past took a month.

ORMs are right answer to wrong question. Currently, they are the choice, since they make life easier in the absence of a better solution. But they cannot handle the level of complexity they aimed to. "Problems cannot be solved by the same level of thinking that created them." A.E

As others mentioned relational databases are heavily used and relied and replacing them forces a lot of risks. Look the interval between SQL versions and the major changes between these versions and other Microsoft products (conservative approach, which is necessary here). Also I'll add the following items:

1. Current approach still works. You may argue it will work forever (we can code assembly yet), but here I mean it doesn't work logically when, the AVERAGE level of projects complexity and the time to develop them on relational databases rings the bell.
2. Major companies did not involved seriously. When the market signals, they do.
3. The problem is not well-defined yet. Unfortunately current failures help.
4. It need some improvements in other sciences (QC, AI) rather than computer. Storing and querying multidimensional data on flat infrastructure and without enough smartness for self-organizing are the top obstacles at the theoretic level.