Can anyone think of some good reasons *not* to use an Object-Oriented DBMS to back a website?

Question

Say you're coding some kind of web application. Something where people can contribute content, e.g. a simple photo-sharing site.

How many good reasons can you think of to not go with an object-oriented database (e.g. db4o)?

Answer 1

I'd only recommend going for OODBMSs if your application design is really, really heavily object oriented, and the complexity presents a need for it. A photo-sharing site doesn't sound like it's heavy on the OO side, so I don't see the point of going for db4o.

However if you really just want to learn the ins and outs of using an OODBMS out of a pet project, it's fine to use one.

Answer 2

An OODBMS is better if you only need to access your data through your objects. If your solution requires additional pathways to your data (e.g. ad-hoc queries, reporting, other applications that need data access but can't make use of your objects), then a traditional RDBMS system is better.

Note: OODBMSes have made a lot of improvement in this area.

Answer 3

Another good reason is relative longevity. db40 is an excellent product for what it does, but its user base is small and it isn't likely to outlive something like SQL Server.

Of course, I also used to say there was no way Java was going to survive.

Answer 4

I don't know how big your plans are, but the availability of experienced and skilled people to hire (or just to lend a hand) would factor into my decision, as well as just a generally large body of knowledge regarding all of the ins and outs of the DB.

Oracle or MySQL have their flaws, but odds are if you have a problem 100 other people have had the same problem and can tell you how to solve it.

Answer 5

Size of data (If I'm dealing with millions and millions of rows, I'm sticking with what I know)

Reporting (Typically difficult enough in normalized databases, worse in OO databases)

Availability of expertise/experience (RDBMS clearly have more adherents)

Large amounts of ETL (Most people import and export in flat files, unless you're getting/sending XML, you're talking plain old tables)

None of these sound like obstacles for your project

Answer 6

This is a bit of a stretch, but to paraphrase a Joel post, plan for success. What if your app becomes really popular?

For example, what if you are hosting your app on your own machine, but decide to go to a formal hosting site, or even a server farm. What are the chances they will support an OODB versus MySQL?

Answer 7

I would say the fact that if you are considering something like db4o that they don't appear to have enterprise examples of powering websites, and are mostly in use for embedded applications.

See my other post on this. (http://www.youtube.com/watch?v=N8XDscWleKw)

Nothing technically in the way here, just adoption it seems. However, for speed of development, maintainence and design flexibility, OODBs are pretty unbeatable.

heavy reporting etc. can be done by synching with a relational back end if required which i know db4o supports

Answer 8

My personal opinion, where there's data ... there's reporting.

No OODBs is going to give your data the appropriate storage model to be available to your reporting applications.

Ron

Answer 9

Need for speed when all you got is a pedal bike. Scenarios include data capture (e.g. logging) where after the event the captured data is often processed at a later stage and probably broken up into its object constituents anyway.

Answer 10

For reporting with db4o please see:

http://developer.db4o.com/Resources/view.aspx/Reference/Implementation_Strategies/Reporting/

Answer 11

Maybe you guys also want to check this article:

http://microsoft.apress.com/asptodayarchive/74063/using-an-object-oriented-d

"Using an OODB in a Website" by Jim Paterson

Best!

Answer 12

For a complex application with modest data needs, you can't beat GLASS (Gemstone, Seaside and Smalltalk). Reporting is definitely something you want to do OO in Smalltalk.