OODBMS and the culture of Lightweight
After a small set of rainy days, the sun is now perfectly visible, here at the border.
The other day I found myself discussing with Piotr, my polish office mate, about Object Oriented databases. He believes there is a kind of “curse” hanging over this kind of DBMS. They work, there are a few implementations, but there’s a lack of interesting projects using them. Maybe Indico is an exception, at this point.
After almost two months of Zope’s ZODB usage, I would say that OODBMS are the future (and not yet the present, because of the lack of interest of the programming community, and some other reasons). With ZODB, I can easily transform my Python classes into persistent classes (without the need of any kind of auxiliary specification of behavior or structure), and add them to the DB (which, in practice, is nothing more than a big tree of Python objects). It’s all done in runtime, without the need for any kind of (pre-)compilation. And the news is: it’s fast! Well, not as fast as a crappy table would be, but it’s an amount of performance that most homebrew applications (and many commercial ones) can afford, in exchange for easiness of programming and a 21st century database paradigm.
Let’s face it. I am wasting computational resources right now. WordPress forces me to use MySQL (yes, WordPress still doesn’t support [at least officially] any other database system). MySQL is a high-performance [and resource consuming] relational DBMS, and this particular instantiation (mine) struggles each day to remain alive, with the limited amount of resources I am provided with by this server. I considered the sqlite option, but… no WordPress support (yes, this one is a killer application)… why? Well, if someone is to blame, it’s the WordPress programmers (not me, for sure): they have made their choice, and for sure they had good reasons to make it this way (if not for something else, for the lack of other widespread open source database servers). Let’s not forget that many people host their blogs in shared virtual servers, which do not provide even an SSH shell, and sometimes not even an MySQL database (yes, plain text files! you’ve guessed it!).
So, in order to use this particular piece of software, I am forced to install an enterprise-level database (although I have parametrized it for low memory usage): I’m killing the fly with the Tomahawk! If only I were able to use a smaller thing, I could spare this processor a little work, and free some memory for some other app. By the way, this webserver is powered by lighttpd… and it works pretty well.
Nowadays, the web requires more and more persistent storage. This storage is usually achieved through relational databases. If in linear programming contexts, this meant simplicity, in the object-oriented age (or post-OO, since we are reaching to the point of things like AOP), it means “big-and-full-of-hardcoded-sql data access layer”. This has been partially solved by frameworks like Rails or Symphony: this layer is built automatically. However, the problem remains: it’s all there! You want to do it different? You’ve got to mess with SQL queries, anyway. You’re just running from the problem, not solving it!
And that’s it for now… feel free to comment on this improvised essay…
Cheers.
Pedro