Object relational persistence
Posted: August 21st, 2002 | 3 Comments »For some reason I’ve always wanted to play with object-oriented persistence into relational tables. This is when you code in an OO style and your objects are automatically persisted into a RDBMS tables without you having to write SQL – the framework converts your object structure back and forth. I wrote a simple class set for h2g2 but I’ve never used any proper frameworks for it. Tangram is a popular system for Perl which Jo recommended; I haven’t really had an excuse to use it yet. There are various systems for Java, since OR is well-suited to J2EE Entity beans, and Hibernate looks really good: very feature-rich, and the documentation definitely talks the talk.
Our experience with this stuff is that it’s horribly horribly shit!
Basically, once you’re using an RDBMS as a place to store serialised objects, you’re better off with something like a raw DBM file. If you’re not really *using* that complex SQL data management layer between the DBM file and your application, then getting rid of it can produce large speed improvements and easier coding.
But this is about more than just using an RDBMS as a big storage vat for opaquely-serialised objects, which is useless. The point is to store this stuff in a database that’s good at querying, and in a way that translates to a proper schema rather than serialising. While these frameworks let you avoid SQL if you want to, they don’t mean that nobody can use it. Your heavy DB coders and admins can write (or use) big SQL report tools, while your appliation coders don’t have to touch that stuff.
Are you talking about the JAWS type thing where the objects are turned into ‘real’ SQL rows? Sorry, I thought you meant serialisation.
SQL is the bane of my life!
Yes, there is more utility in that approach, but there are impedance matching problems… that’s what container managed entity beans in EJB try to do, but keeping schema and class in synch can be a problem, as can inheritance; I’ve not seen it done elegantly yet.
I’d rather just ditch SQL