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 Faine
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:> 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.
>
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---