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.
Point rails to a temporary table or view in Oracle.
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.
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.