Dani Dani wrote in post #962064:
> Thank you Marnen and Phoenix for your detailed explanations.
> I do understand the functionality of the foreign key. I just was not
> sure
> whether relying on rails's foreign key functionaliy is good enough and
> there is no need to do it directly on the database, but now reading
> Phoenix's explanation, I understand that as long as only my rails
> application is accessing the database, I can rely on rails's foreign key
> functionality. Of

But you can never guarantee that.   In virtually every Rails application 
I've worked on, I've needed to use a DB administration tool at some 
point to tweak a value or check a field definition.  In other words, 
I've needed to use a non-Rails interface at some point, and therefore 
I've needed the data integrity checks of a foreign key constraint.

Working without foreign key constraints is playing with fire.  It may 
look like it is working, but you'll be setting yourself up for subtle 
bugs that may not be immediately obvious but will cause you no end of 
grief when they occur.  Don't ever do that.

Moral: if you care about the integrity of your data, you need physical 
constraints in the DB to ensure that integrity.  If you don't care about 
that integrity, don't waste time storing the data. :)

>
> Thank you again.
>
> Dani

Best,
-- 
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org

Sent from my iPhone

-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to rubyonrails-t...@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en.

Reply via email to