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

Tightwad

What attracts me to OODBMS's is the ease of setup. Instead of planning a database schema, setting up the database, deciding which ORM to go with, setting up the ORM, blah blah, I can just code my object and have them persisted automatically. – Tightwad

Answer 1

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.

Torry

I have a strategy for this. All the data objects will be in a separate class library called "Model". The other projects including the main Web project will reference this project. This way, there's one central location to maintain the schema. (I can use interfaces, etc to maintain compatibility). – Tightwad

For ad-hoc queries and reporting the OODBMS is in general far superior to any external applications (at least Gemstone is) – Corroboration

Most of my clients have people who know how to write reports against SQL Server (they know how to write SQL Queries and how to use a particular designer like ActiveReports or Crystal Reports and how to run and deploy). Gemstone might be awesome, but none of these people know how to use it. – Torry

If they are smart enough to handle SQL joins they will not have trouble learning Smalltalk. – Corroboration

@Stephan: I assume you're kidding? – Torry

Answer 2

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.

Painterly

Answer 3

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. (Example websites using db4o)

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

Hair

Answer 4

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?

Psychodrama

In case of db4o you don't need the host to support it. It's not a server! – Mechanics

Be careful of medium trust environments... however if you have a VPS or Colo or Dedi server, then db4o away! – Pedagogue

Answer 5

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.

Goatish

Answer 6

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.

Torry

Answer 7

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

Tootsy

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.

Godwit

Gemstone is a distributed Smalltalk image. There is no better storage model for reporting. – Corroboration

Your statement doesn't make too much sense: to do the reporting, you must query the data store. As long as you can do that, you can report on what's in there. Doesn't matter if its relational, object, xml, document, or flat-file. – Pumpernickel

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.

Erdah

Answer 10

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!

Kaleb

Answer 11

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.

Corroboration