Database Abstraction - code vs infrastructure

John Wang — Tue, 04 Sep 2007 23:38:00 -0500

I've worked on a number of database-driven projects and no matter how much people want database abstraction, it was always difficult to code and maintain. I was recently reminded of this when I read this Drupal article on dropping PostgreSQL support. Not only can it be difficult to maintain support for multiple databases, but it may be difficult to find developers.

One solution of modern programming is to move database abstraction from the code to the infrastructure using a ORM (Object-Relational Mapper) or Data Mapper. A ORM and Data Mapper abstracts the database for you so you no longer have to do tie db abstraction to each app. Not only does it let you code once for multiple databases it lets your users migrate their data from one database to another. This blog runs Typo which is based on Ruby on Rails and ActiveRecord. I've been contemplating migrating Typo from MySQL to PostgreSQL and I've been told that it would be as simple as exporting the data with YAML, updating the database.yml file and importing the data. I haven't gotten around to doing it yet but it is a powerful idea. ActiveRecord is a data mapper and isn't as flexible as a full blown ORM but it gets the job done for the most part. For a full-blown ORM, I think of Perl's DBIx::Class which provides a full OO interface to the RDBMS allowing you to code just once for multiple DBs without limiting you when you want to use some esoteric database-specific SQL. DBIx::Class is often used with the Catalyst Framework but is also used by itself.

There are PHP frameworks out there like Symfony and Cake but do any of them have stand-alone ORMs? If so, could Drupal move to something like that and solve their maintainership problems once and for all? Drupal is part of the Go PHP5 effort so there should be no issue using PHP 5 OO. Something to think about for the Drupal folks if a PHP ORM is available.

ActiveRecord - Achilles Heel of Ruby on Rails?

John Wang — Sun, 04 Jun 2006 11:12:00 -0500

IMO, one of the major limitations of Ruby on Rails compared to other frameworks is its ORM, ActiveRecord. ActiveRecord is a fairly early ORM (object-relational mapper) that has made some questionable design decisions and doesn't support some very basic relational database concepts. These issues have been discussed on Joel on Software and elsewhere. Here are some limitations I wish were fixed:

No Foreign Key Support: Although RoR lets you define has_many relationships, it makes no effort to create foreign key constraints in the underlying database to ensure relational integrity.
No Multi-column Primary Key Support: Multi-column primary keys are a staple of relational database schema definition. Unfortunately, DDH had a pretty simple response:

> Is there a way to set an ActiveRecord object to point to a table
> with a multi-column primary key?

Not really, no. Active Record was designed for a single column primary key and that assumption runs pretty deep. AR is not a Data Mapper, so you have to be within a reasonable vicinity of its assumptions to enjoy it.
- David Heinemeier Hansson

As DHH says in his multi-col PK response, you need to be close to ActiveRecord's assumptions, it doesn't cater to your situation. ActiveRecord is nice for many simpler situations but if you want relational integrity and/or have complex relationships, it seems like it may not be the best tool for the job. Other ORMs such as the Perl-based DBIx::Class (often used with the Catalyst framework) can handle these issues and many more. According to the 37Signals blog entry Growing in vs. growing out, they prefer people to grow out of their applications. I'm curious if they also want people to grow out of ActiveRecord?

Dev411 Blog: Category activerecord

Database Abstraction - code vs infrastructure

ActiveRecord - Achilles Heel of Ruby on Rails?