postgresql iconcatalyst iconperl iconmysql icontypo iconphp icon

Database Abstraction - code vs infrastructure

Posted in , , , , , , Wed, 05 Sep 2007 04:38:00 GMT

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. Abstraction - code vs infrastructure digg:Database Abstraction - code vs infrastructure reddit:Database Abstraction - code vs infrastructure spurl:Database Abstraction - code vs infrastructure wists:Database Abstraction - code vs infrastructure simpy:Database Abstraction - code vs infrastructure newsvine:Database Abstraction - code vs infrastructure blinklist:Database Abstraction - code vs infrastructure furl:Database Abstraction - code vs infrastructure fark:Database Abstraction - code vs infrastructure blogmarks:Database Abstraction - code vs infrastructure Y!:Database Abstraction - code vs infrastructure smarking:Database Abstraction - code vs infrastructure magnolia:Database Abstraction - code vs infrastructure segnalo:Database Abstraction - code vs infrastructure


rails icon

ActiveRecord - Achilles Heel of Ruby on Rails?

Posted in , , Sun, 04 Jun 2006 16:12:00 GMT

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:

Read more... - Achilles Heel of Ruby on Rails? digg:ActiveRecord - Achilles Heel of Ruby on Rails? reddit:ActiveRecord - Achilles Heel of Ruby on Rails? spurl:ActiveRecord - Achilles Heel of Ruby on Rails? wists:ActiveRecord - Achilles Heel of Ruby on Rails? simpy:ActiveRecord - Achilles Heel of Ruby on Rails? newsvine:ActiveRecord - Achilles Heel of Ruby on Rails? blinklist:ActiveRecord - Achilles Heel of Ruby on Rails? furl:ActiveRecord - Achilles Heel of Ruby on Rails? fark:ActiveRecord - Achilles Heel of Ruby on Rails? blogmarks:ActiveRecord - Achilles Heel of Ruby on Rails? Y!:ActiveRecord - Achilles Heel of Ruby on Rails? smarking:ActiveRecord - Achilles Heel of Ruby on Rails? magnolia:ActiveRecord - Achilles Heel of Ruby on Rails? segnalo:ActiveRecord - Achilles Heel of Ruby on Rails?