Persistence

The deeper I look into persistence, the more confused I get.

In the old days, it wasn't too hard. We wrote our SQL, muttered a swift prayer to Codd, and away we went. In the even older days, we used native access methods, but there was still an RDBMS underneath.

In fact, the first systems that I worked on used flatfile, tapes, and DB1, all under PL/I. But my memories of that time are lost in the mists of Guinness.

But now, it's all very different. It isn't just data that we want to persist, it's objects. And from what I can tell, there isn't a generally accepted right solution to this.

One approach is to map objects onto tables in an RDBMS. Castor JDO can do this, as do Entity EJBs. In fact, there are many such frameworks. The advantages of this are obvious, especially to those of us who are comfortable with SQL. (My friend Steve used to whistle The Ride Of The Valkyrie when I was doing SQL updates.)

But it isn't very OO, is it? Not very twenty-first century.

Then there are OODBMSs. Java has Ozone, about which I know nothing, and Python has ZODB, which I've used, and is pretty funky.

Somehow, though, I can't see OODBMS replacing RDBMSs. Perhaps it's just that I've not got used to them. But when I first learned about RDBMSs, a light went off in my head - I knew that they were just right. I get no such flash of light from OODBMSs. But then, what do I know?

I suppose that there is always pickle. For Python, at least...

Update 11th November: A couple of approaches I neglected to mention. You can persist to XML. Castor does this, in addition to being able to persist to an RDBMS.

Then there is the Prevayler/PyPerSyst approach - keep everything in memory. Which is OK for small data sets, I suppose...

Posted to Software development by Simon Brunning at November 08, 2002 01:44 PM