12

Why did object oriented databases fail?

I find it astonishing that:

foo bar = new foo();

bar.saveToDatabase();

Lost to:

foo bar = new foo();
/* write complicated code to extract stuff from foo */
/* write complicated code to write stuff to database */

Related questions:

Are Object oriented databases still in use?

Object Oriented vs Relational Databases

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

Community
  • 1
  • 1
user128807
  • 10,179
  • 16
  • 49
  • 72
  • This might be a bit subjective/inflammatory. Wiki? – unwind Jul 15 '09 at 12:45
  • 1
    It's worth noting that even without OO databases, your first snippet of example code is still very much possible these days using ORM solutions such as Hibernate (though I appreciate that the boilerplate code is still there somewhere...) – William Jul 15 '09 at 12:51
  • Use an ORM and live happily ever after – masm64 Apr 03 '16 at 19:48

11 Answers11

14

Probably because of their coupling with specific programming languages.

Aamir
  • 13,616
  • 6
  • 40
  • 65
  • Good point. Many databases need to be accessed by a wide range of applications. – Meta-Knight Jul 15 '09 at 13:01
  • It's good architecture to decouple data and programming language. I hate to share the DB between several apps. Too much business logic in the data layer. – ecoologic Jan 04 '18 at 05:52
10

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.

jalf
  • 229,000
  • 47
  • 328
  • 537
  • 4
    If I'm coding in an OO language (Java or C#), what data do I have that is relational in nature? Everything is in an object. – user128807 Jul 15 '09 at 14:28
  • Just because everything is an object in your programming language doesn't automatically mean that it should be one in your database as well. you might want to perform queries that don't map directly to the object structure. Or you might have data from several different object models stored into the same database. You might have different objects representing the same data in different applications. – jalf Jul 15 '09 at 14:45
  • Datomic could be viewed as an Object Database, just not of the first generation sort. – karmakaze Apr 18 '19 at 18:23
7

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.

ecoologic
  • 9,297
  • 3
  • 55
  • 62
Halvard
  • 3,655
  • 6
  • 33
  • 49
6

There are countless numbers of existing applications out there storing their data in relational databases. This data is the lifeblood of those companies. They have collectively invested huge amounts in storing, maintaining and reporting on this data. The cost and risk of moving this priceless information into a fundamentally different environment is extremely high.

Now consider that ORM tools can map modern application data structures into traditional relational models, and you remove pretty much any incentive to migrate to OODBMS. They provide a low-risk alternative to a very costly high risk migration.

skaffman
  • 381,978
  • 94
  • 789
  • 754
  • InterSystems M came to light in 1979, exactly the same year as the first RDBMS by Oracle was released. I think the question is more why ODBMSes failed back in the 80s. – Alexey Zimarev Nov 04 '18 at 14:30
5

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.

chaos
  • 115,791
  • 31
  • 292
  • 308
3

I think it is because the problem was solved differently. You might be using a relational database behind the scenes when you are coding in Ruby on Rails or LINQ to SQL, but it feels like you are working with objects.

Jan Aagaard
  • 10,130
  • 7
  • 40
  • 66
2

Very subjective, but a few reasons come to mind:

  1. Performance has not been as good as relational databases (or at least that's the perception)

  2. Again with performance - relational databases allow you to do things like denormalizing data to further improve performance.

  3. Legacy support for all the non-OO apps that need to access the data.

Eric Petroelje
  • 57,359
  • 8
  • 118
  • 174
  • 1
    The Stanford Linear Accelerator Center has apparently the largest database in the world, and it is an object oriented database. Maybe I'm wrong, but to me that indirectly says something about the performance. – Halvard Jul 15 '09 at 14:23
1

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.

Dave Markle
  • 88,065
  • 20
  • 140
  • 165
1

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.
Xaqron
  • 26,135
  • 39
  • 130
  • 194
0

Why not?

I guess they were a solution to a problem nobody was having, or not having enough to pay for it.

John Saunders
  • 157,405
  • 24
  • 229
  • 388
0

Further, OOP and set-based programming are not always very comptatble. Personally, when I started reading about OO databases, I couldn't help but think "Boy, I hope I never have to work on one of those, update 1 million rows out of a 6 million row table and then make sure all appropriate records in other tables get updated as well"

moleboy
  • 864
  • 1
  • 8
  • 17