On Thursday 13 April 2006 14:16, Bill W. wrote:
I’d like to better understand the criticisms I’ve seen of Rails’ ability to
handle legacy data. The ones I’m interested in are those based on Rails’
naming conventions for tables. In my experience in large corporate
environments programmers / programs don’t access db tables directly. They
access views of those tables. And, to my understanding (and I’m not a
dba), the name of a view is independent of the underlying tables, and a
column in a view does not need to be named the same as the column in the
table the view maps to. So I’m wondering…
Can Rails be used on a view? Or does AR not support views for some reason?
A DBMS should present views to the world just like tables. There should
difference at all in using them in Rails or anything else. Any database
system that makes you treat views differently is Bad Software, although
not aware of any that do.
We use PostgreSQL for all new apps we write, and I now frequently make
views to reshape third-party data into a more suitable format. You have
make rules to tell the view how to map inserts, deletes and updates to
base tables, but once that is done you can use them as tables. Other
have different ways to make views updateable (IE, act like tables). I
suppose a database that does not have updateable views could not be used
you describe, but I’ve not used any myself.
If you are switching an app to Rails, you could create a new,
based schema, import your old data, and they produce a set of views so
legacy applications can continue to access data in the same way they
have (for the migration period). Obviously, if you want a legacy app
Rails app accessing the same database, you must make sure you have all
necessary constraints in place so that one app or t’other doesn’t go
inserting incomplete/incorrect data because the views are wrong. But
always an issue with multiple applications hitting one DB.