Home > blogroll, Commentary > Object Oriented Databases

Object Oriented Databases

While working on a side project, I had a thought to test an object-oriented database. My requirements are very narrowly focused and I’m in complete control of the environment, so I thought this would make a good test-subject.

I looked around and found the comparison of oo databases on wikipedia. Since I’m working in C#/.NET, I need an oodb that supports .NET well. I also prefer to find something with a community or start-up license, since I can’t afford to spend money on this. I also talked to a colleague, Jeff Panici, who recommended looking at Poet.

I first tried DB4O, since it had a demo available. The licensing requirements were a bit vague, but I thought I could work through the issue. I implemented a new database class in my Zifmia Service using DB4O and was successful at the first line of unit tests, but as I got into the deeper aspects of my object graph, DB4O seemed to act strangely. Then I inquired about the licensing issue and surprisingly, Versant expects royalties. I assume this is for mobile implementations, but apparently it’s across the board.

I will say I got the OODB bug bad. Using DB4O was light years easier than using SQL Server and managing the mappings between relational tables and objects. Just removing the need to think about relations and tables saved me an enormous amount of effort. I was determined to find an OODB solution for Zifmia at this point.

I then looked for Poet and discovered that Versant had purchase Poet and has it “hidden” from testing, use, or even purchase. I assume Poet was a legitimate competitor to their main OODB and so they bought it and took it off the shelf. This left me feeling like Versant wasn’t a company I wanted to deal with, so I went back to the comparison list.

The next OODB I looked into was Eloquera. This had everything I needed and even better, it was an almost exact match in usage patterns to DB4O. I had to update my code a little bit, but most of the Linq queries I implemented remained unchanged. I have since been able to implement all of my unit tests with success. There is one issue though. the performance is less than ideal. It’s not terrible, but it is suspect. With a very simple object graph and what is essentially 13 objects in a 3-level graph with a couple of circular references, saves are taking 3 to 5 seconds. Loads are <1 second, but the saves are a concern. It’s also slow handling large byte arrays (7MB). SQL Server was never a bottleneck for any of these interactions, but the I was doing all the mapping with SQL Server.

I’m completely in love with the OODB concept and Eloquera is great, but I’m hoping I can work with the development team to get past the performance issues.

That said, I wonder why Microsoft doesn’t create an OODB. They certainly have the know-how. It may confuse their SQL Server customers, but it may also provide an alternate solution to problems that are founded on objects, not on relations. I suspect that anyone at MS Research that’s interested in OODB development is quietly asked to choose another subject-matter. SQL Server is probably one of the golden geese and tampering with its identity at MS is likely taboo.

Follow-up: I found a 6 year old MSDN article that claims OODB’s are dead. An interesting and incorrect notion. The argument is that companies will never abandon the relational model and the problems in managing object graph changes is too complex. I’ve managed the upgrades of relational models and let me tell you that’s no picnic either. I do understand how a larger company wouldn’t want their payroll or invoice systems in an OODB. There’s too much gravity in relational database systems backing those types of vertical products. But that still leaves a ton of room for single purpose systems, mobile applications, and small business systems. These types of implementations aren’t “corporate” and can be adapted to the OODB concept. And if there’s ever a need to change the objects, it doesn’t get any simpler to write data movement Linq statements to do that work. Given two different object models, I could write a mapping program in very little time. Doing the same for a relational database would take much longer, even using tools like SSIS.

I think the MSDN artical was seriously mistaken in its grasp of how much more effcient an OODB can be.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: