I've vented before on this blog regarding my frustrations with Hibernate as an ORM solution... and I'm not so sure I like ORM altogether. It's like trying to screw in a phillips screw (relational DB) with a flathead screwdriver (object-oriented language). You know it's not the correct tool, but you really don't wanna switch screwdrivers and go grab something new. With enough fiddling you'll probably be able to screw in the philips screw in, but it takes an incredible amount of finess, frustration, and patience to get the job done. Then taking the screw out later is a big pain in the ass since you stripped it putting it in with the wrong tool.
Why not grab a new tool altogether (object database) and watch as the two pieces fit together nicely. A phillips screwdriver for the phillips screw.
That was the most painful analogy ever.
For real though, I have been wanting to play around with an object database for some time now. My database design and analysis class at UST was really making me even more anxious to play with one. I'm not saying that object databases are the answer yet. Goodness knows that [insert name of huge company] could never run its operations off of such a young technology. I'm just saying that I'm going to stick to CRUD (create, read, update, delete) when dealing with a relational database, and I'll interact with the database like an object when it's an object database. ORM is not the right way to go about this mismatch.
I am trying out db4o
because it's dual licensed under the GPL and a commercial license, and
seems to be the most stable/active choice out there in the open source
landscape.
So I read through a bit of the API and through chapter two of the tutorials tonight and decided to write a little Person class to persist some data about a person. I won't go over any code samples with this first post because I'm no more competant than the tutorials, chapter 2. I will show a screenshot of my two people in a database though, using the db4o Eclipse plugin. I also checked out their Object Manager package and it's quite nice as well. It let's you connect to your DB and view it in a good ol' familiar tabular format :)
All in all it was a fun night. I'll blog about it more as my experience justifies me writing sample code. Here's a screenie though:
Your frustrations on Hibernate are based on your shallow knowledge understandings of an OC4j framework. Hibernate is 'de facto' standard in developing java database solutions (along with JPA). It is used because of the relational database standard storage. Try tosell an critical enterprise application with an Object Database storage....
If Hibernate is the new de facto standard I'd rather be out of a job as a J2EE web developer. My knowledge of it is not shallow (I have to maintain two Hibernate applications at my job) and I know OC4J quite well (It's the application server we use at my job). I'd rather manage straight SQL and transactions by hand and wade through the CRUD than deal with all of Hibernate's shit. CRUD may be more expensive to develop up front but your DBA's don't look at you puzzled when you try to explain Hibernate to them. They can help optimize a SQL query. You don't have to deal with Hibernate's sessions shit (although Spring Framework's implementation helps). And I'd never have to fiddle with an hbm.xml file ever again.
I made it very clear that I don't see my tinkering with object databases as an enterprise solution. To quote my original post, "Goodness knows that [insert name of huge company] could never run its operations off of such a young technology. I'm just saying that I'm going to stick to CRUD (create, read, update, delete) when dealing with a relational database, and I'll interact with the database like an object when it's an object database. ORM is not the right way to go about this mismatch."