The Old Joel on Software Forum: Part 4 (of 5) - Object-oriented databases ??

Object-oriented databases ??

I am working on an app where the data is very heirechal. Inheritance everywhere! Was going to use RDBMS, but it is kludgy. Someone suggested using an OO database.

I have never used one, but last time I read up on these (about 2 yrs ago), no one seemed to have anything good to say about them.

Has anyone here used them before? Any recommendations? Might it be worth looking at the Object Relational Databases? Are there significant performance issues?

Tapiwa
Wednesday, March 3, 2004

No real world experience but I looked into Infrasystems Cache 18 months ago and got a free day on their introduction course.

Looked pretty good and apparently IBM use their product. The only drawback for me was that, at the time, there was no decent .NET interface. Don't never whether this has changed in the last 18 months or not. Really it seemed best if you used it form their proprietary web based framework, CSP (Cache Server Pages).

I believe that Cache works using sparse array principles. When I thought about how I would design an Object database it didn't seem that it there was a radically new data storage method involved but just a better interface to, or additional layer over, existing ideas.

Gwyn
Wednesday, March 3, 2004

May I suggest one little piece of knowledge from Anders Hejlsberg:

http://www.artima.com/intv/abstract.html

Dewd
Wednesday, March 3, 2004

http://www.dbdebunk.com/

Wednesday, March 3, 2004

I've worked with Versant v6.1 over a period of about a year in the financial industry from both Java and C++ (and even C but using that interface is, in the words of one otheir support engineers, "like having root canal done without anaesthetic").

From this experience at best I would rank OO db's as ok - it does save you quite a lot of time going to and from table structures but you have other concerns like the fact that few other people can understand your code, it's quite hard to access the data other than directly in your OO programming language (i.e. VB6 etc have little hope and versant's tools were awful slow java messes), the query languages look like SQL but behave differently for where clauses and join-like operations and so are quite tricky to handle if you're used to relational databases. Changing your classes at all (ie. adding or removing an attribute) can cause everything to come crashing down in a heap and could become a nightmare to upgrade applications without having real database migration problems. Additionally the lead time it can take to get your head round everything is quite long and not something many people have time to learn before starting a project.

In addition because you use the objects and classes just like any others (except they derive from a PersistentObject base class) it's very easy to write inefficient code where lots of network calls are implicit and you can have issues with objects cached in local memory being linked to those on the database and holding locks etc etc that are not at all obvious.

There was a Java Data Objects standard in draft form when I was looking at this in 2003, not sure of the current state but it was looking to standardise this stuff which would help a lot if you're using Java.

My experience was not a good one though the versant support engineers were pretty helpful. I wouldn't want to design an application around an OO database if i had the choice.

mutabled
Wednesday, March 3, 2004

I really like object databases. I program mostly in Java and it is so much easier to store objects in an Object database. The question is, does the nature of your program mean you are mostly stroing and retrieving objects or is there a need to retrieve the info in a more relational way. It should be simple to answer the question. Imagine getting your information my navigating an object hierarchy and imagine getting your data via SQL calls. Which seems simpler.

The problem with Object databases is that a) You will never be able to convince your organization to use one b) If you need to scale the really good ones are unjustifiably expensive (at least as of the last time I checked a few years ago- the top vendor wanted to sell me a dev license for $10,000?!?!?!!?) and 3) You will have to deal with all the members of the relational cult thinking you are an idiot and licking their chops awaiting the day you leave so they can re-write your crap in a proper database.

As for Cache (Itersystems BTW) it is not really an object database. They call it a "Post-Relational Database" and it is really a few layers over an old (mature, stable, established?) language originally called MUMPS and now standardized as "M". It stores things in Strings as sparse arrays but I think the arrays are limited to 255 length so when they get larger they must resort to trickery. I have used the product, tears ago, with Java. It was good and seemed pretty fast, though I never really stressed it. It runs on everything and has the advantage of storing objects hierarchically but being queriable via SQL. It is a nifty compromise.

name withheld out of cowardice
Wednesday, March 3, 2004

Caché is produced by InterSystems (www.intersystems.com) and they do now have .NET support.

They seem to have conquered some niche markets (e.g. healthcare), but I wonder if they'll ever reach the mainstream.

Steve Jones (UK)
Wednesday, March 3, 2004

The one thing I liked about Intersystems (I should remember the name as they keep sending me literature!) was that they were very willing to make their product cheap for startup type uses and would treat you with as much respect as they would their biggest customers. Apparently this is a company ethic from the founders. And they understand that small fish can later become big fish.

Their attitude was different from the mainstream and I liked it. But sadly not the product (enough)

Gwyn
Wednesday, March 3, 2004

Sounds like they've been reading "Crossing the Chasm".

I also found them to be very helpful, but didn't quite feel comfortable enough to use the product. My main reason was it'd take me ages to find out if it really worked for my situation, time I just didn't have.

Steve Jones (UK)
Wednesday, March 3, 2004

Here's a link to one I used a long time ago. It was fantastic at that time, so I imagine it's only improved. When I used it, though, it was programmed in Smalltalk. Not sure if that's still a requirement. Might be worth checking out, though:

GemStone: http://www.gemstone.com/

former gemstone user
Wednesday, March 3, 2004

A previous employer is droping an OODBM for a normal RDBM system because of issues with performance. The OODBM would cause issues and at 30000 - 100000 records it would grow to slow to be useful. This happen with two seperate OODBMs. I personally do not think that in the long run the ease of api usage buys any major advatage over a RDBM at all.

A Software Build Guy
Wednesday, March 3, 2004

PostgreSQL supports table inheritance, which makes it very easy to map object hierarchies to tables (so long as they're only single inheritance). I have tried it, and it does work. And PostgreSQL is a superb database anyway, so it's worth having a look to see if it'll help your situation.

Matt
Wednesday, March 3, 2004

This is a question that is as old as the hills (or at least as
old as many younger programmers). The "impedance
mismatch" has been talked about since the early 80's,
when OO first started appearing. The problem is that
OODB's tend to fall into the "what is OO" trap; they
either try to be tightly coupled to a particular language like
C++ (the downfall of the first generation of O-companies),
or they are so generic that they end up competing
directly with RDBMS's - and losing, since DB customers are
enormously conservative and know RDBMS technology
very well (the downfall of UniSQL, as well as why
O2/Fresher isn't doing better, despite having excellent
technology). Also, older database veterans know that
many OODB's are often just CODASYL databases (vintage
1970) with updated terminology - but with many of the
same problems and issues that hierarchical databases
have always had.

Those who think there is some vast conspiracy to keep
"better" OODB's from winning are just silly and don't know
their history - DBMS's are the perfect example of how those
who don't know history are doomed to repeat it...

(Disclaimer: I build relational database engines for
embedded systems for a living, so I'm somewhat biased...)

x
Wednesday, March 3, 2004

You are making a fundamental mistake that will haunt future developers / enhancers of your system forever.

THERE IS NO SUCH THING AS HEIRARCHAL DATA.

Heirarchies are a VIEW of data, from a very tight perspective. Change your perspective and the model falls apart.

Organise your data according to a properly normalised relational model and you will have the flexiblity to grow and change as future needs might require.

HeWhoMustBeConfused
Wednesday, March 3, 2004

Some handy links:

http://www.c2.com/cgi/wiki?LetsUseAnObjectOrientedDatabase
http://www.c2.com/cgi/wiki?ObjectsVsRdbmsPerformance
http://www.c2.com/cgi/wiki?ObjectOrientedDatabase

John Rusk
Wednesday, March 3, 2004

I'm Access free!

http://www.sleepycat.com/pdfs/wheresthecat.pdf

fool for python
Thursday, March 4, 2004

http://www.inconcept.com/JCM/March2004/Pascal.htm

MR
Friday, March 5, 2004