views:

211

answers:

2

What are the usual problems / stumbling blocks / issues / drawbacks when using a legacy database with a new rails application?

We have to decide between using an old database or writing migration scripts to bring data from old database to new database following rails conventions. What would you suggest?

A: 

1) Typically the first issue is the database schema design has composite primary keys (multi column keys), where Rails (or at least ActiveRecord) wants primary keys named "id". Many good data models don't use surrogate keys, they use natural keys, so they cannot avoid composite keys. In practice, when designing a new database for an ORM, it is more practical to use surrogate keys named "id", but enforce data integrity by always including an alternate key constraint / index on the natural key.

2) Table naming that uses plural vs singular (Rails wants plural to map to its domain objects. With many databases this can be overcome easily with synonyms.

Those are the two issues I've run into with Rails and other MVC frameworks, but some have changed in the past couple of years and provided alternatives to simplistic nonsense. It is expensive to change a legacy database, and enforcing a naming convention is a big mistake which I believe has been learned now.

mrjoltcola
A: 

Table naming was one that got me for a while. The trick was to use this in your models:

set_table_name  'old_table_name'
set_primary_key 'old_key_column'

That way you can use whatever model name you want while linking to any table you want.

Jarrod