It’s much easier to use Rails for new applications than to try to layer Rails on top of existing applications and their underlying databases. That said, once you’re comfortable in Rails, there are many times when you’d like to replace an old system but keep the underlying data. If by some chance the creators of the tables followed Rails’ conventions for names that are singular, for names that are plural, and for identifying primary and foreign keys, it might not even be that painful. Here are a few alternate paths forward you’ll need to consider:
If the legacy application already has a web service interface of some kind, you may be able to write some transfer code that sends all of that data to a new Rails application, which then structures it however is needed. This avoids any tinkering with the existing database, but may present challenges all its own. If you need to make substantial changes to the data structure anyway, though, it may not be too much extra work.
If you’re comfortable renaming tables and columns inside your database, you may be able to modify the database so that it follows the conventions Rails expects. For a small project with just a few tables, this might be an acceptable path, but it could be a lot of work for an application with many tables. You’ll still, of course, have to write a Rails application that knows how all of the database tables are connected, as Rails won’t pick that up automatically.
Rails was built to work on naming conventions, but if you
have to fall back to configuration, you can write model classes
that override the usual conventions. A model can specify, for
example, that it works on a table other than the one its name
suggests by setting a value for self.table_name('
,
or it can specify that the primary key is a specific field with
table_name
')self.primary_key('
.
The column_name
')ActiveRecord::Base
class offers a
lot of control.
All of these paths require you to do some extra work, but they can certainly be your next steps for learning Rails.