Linked by Thom Holwerda on Fri 7th Dec 2007 19:44 UTC, submitted by Bill Davenport
General Development Ruby on Rails 2.0 has been released. "Rails 2.0 is finally finished after about a year in the making. This is a fantastic release that's absolutely stuffed with great new features, loads of fixes, and an incredible amount of polish. We've even taken a fair bit of cruft out to make the whole package more coherent and lean." On Zenbits, they give tips on how to install 2.0.
Thread beginning with comment 289464
To view parent comment, click here.
To read all comments associated with this story, please click here.
segedunum
Member since:
2005-07-06

Is it possible to have compound primary keys in Rails 2.0? I remember reading that the Rails developers explicitly rejected compound primary keys in Rails 1.0 because they thought there was no legitimate reason to have them

The only reason to use them is for legacy database reasons, but even then, you'd be better off refactoring and normalising your database design - although, as borker says, I'm not keen on having peripheral stuff in my databases that isn't related to the actual data.

Edited 2007-12-07 23:25

Reply Parent Bookmark Score: 1

franzb Member since:
2007-12-08

An interesting link with a discussion on composite primary keys:

http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_prima...

I've read it all and now am really asking myself how ignorant can the Rails developers get?

Summary: Rails encourages sloppy db design!

Reply Parent Bookmark Score: 1

Richard Dale Member since:
2005-07-22

I read the discussion and about half the people making the comments disagree.

Identity key sequences are used for primary keys in Rails because DHH and others are of the 'opinion' that way is better, not because they are sloppy db designers. Rails is 'opinionated' software, and if you don't agree with the principles on which it is designed then you are free to use another framework. They would rather keep Rails lean and simple, instead of trying to be all things to all men.

Reply Parent Bookmark Score: 4

FooBarWidget Member since:
2005-11-11

"Summary: Rails encourages sloppy db design!"

"not using composite primary keys = sloppy db design" is merely an opinion, not a fact. The Rails developers disagree with that opinion, and Rails is opinionated software.

And I agree with the Rails developers. The website that you link to says that the autogenerated identity key is redundant because (CustomerID,ProductID) already uniquely identifies a table row. And he's right, but that's not enough reason *against* using an autogenerated number, I simply do not see the problem. Next, he says that using an autogenerated identity key increases complexity. Yeah in this specific case he might be right, but read http://rapidapplicationdevelopment.blogspot.com/2007/08/in-case-you... for a rebuttal.
The biggest problem I see is that composite primary keys make foreign keys ugly and large. Furthermore, Rails uses the autogenerated integer identity key in URLs, for beautiful RESTful URLs. Can't do that with composite primary keys.

And finally, how do you define "sloppy"? To me, a database design is good if it's easy to understand, easy to maintain and easy to work with. The fact that composite primary keys makes foreign keys so large makes the database hard to work with (ugly and large SQL queries).

Reply Parent Bookmark Score: 2

segedunum Member since:
2005-07-06

Well, although I'm not keen on additional data, that's the way Rails works and that's the way that Scaffold works amongst other things. You have to weight up using Rails and Scaffold against keeping your data 'pure', as it were.

Reply Parent Bookmark Score: 2