Newbie Question

Rails
1

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.

2

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.

3

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?

4

I’m not sure what the current status on composite key support is.
Perhaps someone else would like to chime in?