Basically, Rails uses the has_many/one belongs_to features to "mimic"
the functionality of a database foreign key. A real foreign key,
however, is built DIRECTLY into the database structure itself instead
of relying on Rails to make it work. This is useful in situations
where you have a Rails application, but other programs or programmers
connect directly to the same database to do work with it. This
happens a lot in corporate setups (data warehousing, etc.)
To illustrate, say you have two tables: users and orders. Every order
has a user_id field that "belongs_to" a user. So in Rails, we could
do:
order = Order.first
order.user # gives us the user
But what happens if we don't go through Rails and instead connect
directly to the database underneath it? Furthermore, if we do that,
then try to save a row in the database without assigning a user_id to
it, or one that doesn't exist, the Rails application (or any other
application that depends on the same database) could break because the
data would be written in a state that the applications using the
database don't expect.
So, in other words, given the same setup, let's say I do this (in
SQL):
INSERT INTO orders ('user_id', 'order_total') VALUES (9912929191999,
29.99);
What happens if there isn't a user with the ID of 9912929191999?
Well, without a foreign key, this SQL query would execute just fine,
because the database doesn't know that user_id is supposed to
correspond to the users table (SQL doesn't really do "convention over
configuration"). Then later, when somebody tries to pull up that
order, the Rails application will probably throw an error 500,
depending on how things are set up, because it'll try to find that
user, that doesn't exist.
A database foreign key prevents this from happening because it'll
first check to make sure that the user with the given ID (in this
example) actually exists before trying to write the row. So when
other programmers or applications access the same database as your
Rails app, if you have foreign keys properly set up, you'll be able to
prevent those other programmers or applications from writing "bogus"
data.
The foreigner plugin/gem adds some methods to the Rails database
migrations to allow somebody to do this without resorting to direct
SQL (so you can build an application on one type of SQL database -
MySQL, PostgreSQL, etc., and deploy it on another - say Oracle or MS
SQL Server [neither recommended, but just used for example]). Since
Rails doesn't build this directly into its own migrations system
(there isn't really an 'add_foreign_key' method in Rails database
migrations without using this plugin), the foreigner plugin/gem adds
them for you so you can use them.
I hope this clarifies things for you. For some further reading, check
out the following:
http://articles.techrepublic.com.com/5100-10878_11-6035435.html
http://en.wikipedia.org/wiki/Referential_integrity
On Nov 16, 8:08 am, Marnen Laibow-Koser <[email protected]> wrote:
> Dani Dani wrote in post #961839:
>
> > Marnen Laibow-Koser wrote in post #961826:
>
> >> And you really can't guarantee that in most cases. Therefore, it is
> >> absolutely essential to have foreign key constraints in the DB, which is
> >> what Foreigner manages for you.
>
> > what exactly is ment here, where can I read about what and how should
> > these
> > "foreign key constraints in the DB" can be done ?
>
> http://lmgtfy.com?q=foreign+key+constraints+in+the+DB
>
>
>
> > Thank you,
>
> > Dani
>
> Best,
> --
> Marnen Laibow-Koserhttp://www.marnen.org
> [email protected]
>
> --
> Posted viahttp://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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
