Using an Object Oriented Database (db4o) for a medium scale application

Question

I came across db4o OODB database and wondering how it compares to a traditional stack with an RDBMS or an ORM like Hibernate/EclipseLink. The application is a workflow system and will expand over time. Not sure if an OODB like db4o fits well. I never worked on an OODB so I can't tell. Any suggestions?

Answer 1

Hi! Here is some information based on my own experiences with DB4O.

There are plenty of choices these days for so called OODB's (Object Oriented Databases). Instead of writing a list of these similar solutions, I can tell you how it works as opposed to using a regular RDBMS, because that was your actual question.

You can read a pretty good comparison of some of the most used systems over at Wikipedia: Comparison of OODB's

If you use an ORM persistent methology with a tool like NHibernate, you're giving yourself an easier time when it comes to querying and updating the database behind the persisted objects. You could think of a tool like NHibernate as a "hybrid" solution, while with pure Object Databases like the one you mentioned (one I've done some work with myself) DB4O from Versant / Actian you can choose to work directly with a file on the file-system or opt for a Client/Server kinda solution. DB4O supports both.

The most common scenario would probably be the former mentioned scenario, where you would use a file on the local system to keep persisted copies of your application's objects.

DB4O now exists as a free for non-commercial use product and has both a Java and a .Net version. They both work the same, and from my personal experience they work pretty good for anything from simple 2-10 Mega-Byte databases to files weighing in at around 10-12 GB's.

As a rule of thumb, according to the DB4O developers, if you expect your application's database needs to be larger than around 15-16 GigaBytes, you should consider other approaches.

DB4O is single threaded, and therefor requires a rather speedy CPU Core to handle large amounts of transactions. But, it manages to run really well considering this obvious limitation.

DB4O is easy to expand and should cover most needs for an Object Oriented Database.

Here is a short example that shows how easy it is to connect to and write a series of custom Objects to the DB taken from one of my own projects: (DbPath is a string constant)

public static void StoreObjectsToDb(IEnumerable<SyncObject> syncObjects)
  {
     using (IObjectContainer container = Db4oEmbedded.OpenFile(DbPath))
     {
        try
        {
           foreach (var hdSyncObject in syncObjects)
           {
              container.Store(hdSyncObject);
              Console.WriteLine("Stored Object with HdID {0}\t<-->\tTfsID {1} to database.",hdSyncObject.HdId,hdSyncObject.HdTfsNo);
           }
           container.Commit();
           LogUtility.WriteToLog("Successfully wrote all objects to database.");
        }
        catch (Exception ex)
        {
           container.Rollback();
           LogUtility.WriteToLog("Could not save objects to database. Rolling back changes...\nError: {0}",ex.Message);
        }
        finally
        {
           container.Close();
        }
     }
  }

So as you can see there is a quite simple way to create a new database and populating it with objects, without needing any form of serialization code in the class definitions themselves.

There are support for many of the traditional RDBMS functions in many of the OODB's and in some scenarios the overhead of implementing a regular SQL database is way bigger than simply embedding the database directly into the source.

Hope this clears things up a bit.

Chris

Answer 2

For somewhat larger applications then Gemstone (a persistent smalltalk) is more suitable. That scales easily to the maximum ram supported by a single machine (2/4 TByte?). In Gemstone you'd typically not denormalize to get optimal performance.