3 ms·

The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less. --- A quick questi

The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less. --- A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)? Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?

amalag 12y ago
To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something. Second question: You can see this answer: http://stackoverflow.com/questions/507179/does-foreign-key-improve-query-performance http://stackoverflow.com/questions/507179/does-foreign-key-i...
- ikawe 12y ago
  Read more about the shortcomings of application level reference validations here: http://robots.thoughtbot.com/referential-integrity-with-foreign-keys http://robots.thoughtbot.com/referential-integrity-with-fore... Note: that post talks about using `foreigner` gem which predates having foreign key support in rails core.
ikawe 12y ago
Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints. Foreign key constraints aren't about performance - they are about maintaining [referential integrity]. previously... pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy owner.pet # what should this equal? Now this will throw an error. pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table. owner.update_attribute(:pet_id, nil) pet.destroy # no problem now. [referential integrity] http://en.wikipedia.org/wiki/Referential_integrity http://en.wikipedia.org/wiki/Referential_integrity

amalag 12y ago

To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something. Second question: You can see this answer: http://stackoverflow.com/questions/507179/does-foreign-key-improve-query-performance http://stackoverflow.com/questions/507179/does-foreign-key-i...

ikawe 12y ago
Read more about the shortcomings of application level reference validations here: http://robots.thoughtbot.com/referential-integrity-with-foreign-keys http://robots.thoughtbot.com/referential-integrity-with-fore... Note: that post talks about using `foreigner` gem which predates having foreign key support in rails core.

ikawe 12y ago

Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints. Foreign key constraints aren't about performance - they are about maintaining [referential integrity]. previously... pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy owner.pet # what should this equal? Now this will throw an error. pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table. owner.update_attribute(:pet_id, nil) pet.destroy # no problem now. [referential integrity] http://en.wikipedia.org/wiki/Referential_integrity http://en.wikipedia.org/wiki/Referential_integrity