I'm very new to Rails and I'm trying, if only for a proof of concept, to develop a quick Rails application to display data from a database. The application will be read only (SELECT statements only) and will simply list data. However, the table structure and schema I have no control over. It basically breaks down into to tables that both contain attribute data. Values that can be repeated are in a table with an _r at the end and values that are always single are in a table with a _s at the end. The tables have a unique identifier row but it is not sequential, and is not an autonumber. The data will be routinly updated by an external process that will not be related in any way to the rails application. Here is an idea I had, please let me know if you think it would work. 1. Point rails to a temporary table or view in Oracle. 2. Update this table or view by using a trigger anytime a modification to the original table takes place. Also, I could use some pointers to information on how to manage these types of scenarios because if I can do this once I'm sure I will be called on to do it again.
on 2007-04-20 17:15
on 2007-04-22 01:51
If your app is indeed read only, and you *can* create views, then that's your best bet. Create a view for each table that fits the Rails conventions. That way, your Rails application will be just like any other. I don't know much about Oracle, but if you could create the views in a different namespace (schema, etc), then even better, because you get to name the views following the Rails conventions for Class <--> table names. Non-sequential ids should be ok. I believe that all ActiveRecord assumes is the existance of a column named 'id' on each table, with unique integer values. Who knows, maybe they don't even need to be integers. As far as updating the views with triggers: again, I don't know about Oracle, but in MySQL and PostgreSQL it is possible to create views that basically just re-write SQL on the fly. No need to store redundant data. And since each one of your views will basically be just: CREATE VIEW widgets AS SELECT foo_r as foo, bar_s as bar, some_primary_key as id from oddly_named_table Then you shouldn't have much performance problems. Those views are one to one with the tables. On Apr 20, 9:15 am, Mark F. <email@example.com>