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. -- Posted via http://www.ruby-forum.com/.
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.
On 2/27/06, Joe Cairns <joe.cairns@gmail.com>
wrote:> 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.
>
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
Nithin Reddy 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? -- Posted via http://www.ruby-forum.com/.
I''m not sure what the current status on composite key support is. Perhaps someone else would like to chime in? On 2/27/06, Joe Cairns <joe.cairns@gmail.com> wrote:> Nithin Reddy 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? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >