On Database Abstraction, PHP, and Ruby
It took me a couple days on my current PHP/MySQL project to get the DB abstraction with proper error handling, input validation, and relational support coded to the point where I’m happy with the model. This was after trying Zend_Db, Doctrine, and Propel, which are all good libraries, but I hit points where the work of getting it to do what I wanted efficiently just wasn’t worth it. I decided it would be faster to just roll my own slim library.
I’m always mystified at why DB models are such a hassle to code, so I spent a little time reading. I think I get it now. It has to do with the mapping problem between relational systems and object oriented systems.
Ted Neward, writer of several books on C# and Java, calls this “The Vietnam of Computer Science“. What he’s saying is that object-relational mapping (ORM) quickly reaches a point of diminishing returns. The problem stems from the conceptual disconnect between the language and the data store.
Hoping to shed additional light on the subject, I went looking for alternative perspectives to my PHP/MySQL solution. Since it’s all the rage for ease of use, I was mostly curious about Ruby, the Rails framework, and object oriented databases.
Ruby is certainly different, but after some reading, I’m starting to understand why the language lends itself better to the OO style of DB abstraction. On top of that, Rails has powerful scaffolding that lets you flesh out pieces very fast without the code getting ugly. With ActiveRecord in mind from the ground up, things can be pretty elegant some times.
I also found some really cool systems for bridging the gap between languages and data stores. For instance, check out MagLev for Smalltalk/Ruby. Imagine using an OO DB so you don’t have to do the relational mapping, doing it in a distributed fashion, and using things like shared memory more efficiently as an object staging area between your running site scripts and the DB. That’s kind of MagLev.
All of this is interesting, but for the current project I’m sticking with PHP. However, on the next project I might try Ruby on Rails. I want to see first hand if and how it overcomes some of the challenges.
On a slightly tangential subject, a part of me really dislikes the weak typing of both Ruby and PHP. The net effect in PHP is that you pretty much end up using arrays for everything, making it hard to keep track of structure. Ruby on Rails does get around some of the weak typing issues with some better built-in validation, scaffolding, and member attributes (I’m not sure if that’s what they call them). Sometimes I’d rather be doing C#.
Rahim Nathoo Said,
June 6, 2008 @ 1:20 am
Very interesting post.
Are you working with any clients or partners that are using OO DBs in their production systems today? Aside from the design elegance that these systems offer, I’m curious about the performance implications of these solutions. In my industry (finance), a DB that outperforms relational DBs for pre-planned and designed-for searches during trading hours, and then slows down somewhat for the ad-hoc queries we have to run overnight to aggregate all the data from the day would be fine in theory. However, it’s the possibility of the constant design changes required during the life of a financial software system resulting in complexity going through the roof and performance being shot to hell that make switching from relational to OO DBs a scary proposition. That being said, I’ve read that companies like Ameritrade and Sungard have already tried this with certain systems. Not sure what their experiences with the technology have been like, though.
What’s the reason for not using C# on your current project? Is it just a platform dependency thing? If so, have you messed around with Mono at all?
Andrew Said,
June 6, 2008 @ 3:57 am
I have not worked with any OODBs yet, so I’m not even sure if they really even are that elegant.
The company behind Maglev, Gemstone, is already in the business of doing OODBs using Smalltalk as the language, and they have some big clients. I don’t really know much about how it’s working out for them, though.
For our web service, I have a couple reasons for not choosing C#.
* PHP, Ruby, MySQL, all these things are free, and so are some nice development environments for them, whereas Windows, IIS, and Visual Studio Pro are not.
* When it comes to web servers, I have way more experience managing real Linux systems than I do managing Windows systems, and right now the overhead of a switch isn’t worth it.
I have tried Mono, but not much.
Dominik Dalek Said,
August 15, 2008 @ 2:54 am
Never used OODBs myself but I know that ORMs lag behind native implementations. Various versions of LINQ (there are 3 types today) are 2-10 times slower (50-10% of speed achieved by handtweaking SQL query). It should improve with time but personally I see no real benefit in case of time-critical applications (online, heavy load, DB bound).