Forum: Ruby on Rails Newbie Question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Joe C. (Guest)
on 2006-02-27 20:45
Hi!  I just ran the first few Rails tutorials and I'm really impressed
at how quickly I was able to get something up and running.

I'm slowly emerging from the stone ages, and leaving my powerbuilder
behind รข?? yes, I know, keep the snickering to a minimum please!  I
started into J2EE/STRUTS, but was quickly frustrated by how long it
would take to code anything but relatively simple applications, and
while I continue to work the java, I knew I had to find something else.

Enter RoR - wow!  I'm really in, well if not love, definitely deep
infatuation.  Naturally, I'm starting to dig through the closet looking
for skeletons before entering into a meaningful relationship though.

The main question I have is: how does RoR play with bad DB design?
Most of the projects I've been working on have consisted of dealing with
connecting to legacy databases.  Sometimes, really ugly legacy
databases, with schemas designed by someone who should be strapped to a
rocket and shot into the sun.

A lot of the design considerations that Rails seems to need to maximize
the horsepower are out of the control of developers in many shops.
Currently, if I asked for a primary key named "customer_id" in a table
named "customers" I would, in a best case, be forced into a DBA
Inquisition meeting, and, after some minutes of torture and ridicule,
simply be told "no".

In short, how much does dealing with ugly data design (and thus ugly
data) foul up RoR?  I know making views could help a lot, but there are
a lot of shops out there that will not allow any of your own objects
into the DB - even if it is in their best interest to do so.
Nithin R. (Guest)
on 2006-02-27 20:52
(Received via mailing list)
Well using your model, you can hide a lot of "ugly DB design" if it is
just naming conventions. You can use something like...

def customer_id
   attribute_read("cust_obj_id")
end

then just call customer_id from then on in your controllers and views.
BTW the table customers should have a primary key simply called "id"
for true Rails semantics.
Joe C. (Guest)
on 2006-02-27 21:03
Nithin R. wrote:
> Well using your model, you can hide a lot of "ugly DB design" if it is
> just naming conventions. You can use something like...
>
> def customer_id
>    attribute_read("cust_obj_id")
> end
>
> then just call customer_id from then on in your controllers and views.
> BTW the table customers should have a primary key simply called "id"
> for true Rails semantics.

Thanks!  Would this also handle a table with a composite key?  Say
consisting of:
id1 number (5, 0)
id2 char (4)
id3 timestamp

If not is there a workaround?
Nithin R. (Guest)
on 2006-02-27 21:32
(Received via mailing list)
I'm not sure what the current status on composite key support is.
Perhaps someone else would like to chime in?
This topic is locked and can not be replied to.