In “Agilge Web D. With Rails” on page 217, an example of
foreign keys is shown.
I am however unable to find a definition of wheater the naming of the
index is significant. On the above mentioned page, this line is shown in
the example:
In “fk_items_product”, “items” is pluralized but “product” is not. Is
this because it is a one_to_many relationship? If so, how should I read
this statement? Does it matter to Rails what the index is called?
Please - somebody must know the answer to this one.
Jakob
Jakob R. wrote:
Hi,
In “Agilge Web D. With Rails” on page 217, an example of
foreign keys is shown.
I am however unable to find a definition of wheater the naming of the
index is significant. On the above mentioned page, this line is shown in
the example:
In “fk_items_product”, “items” is pluralized but “product” is not. Is
this because it is a one_to_many relationship? If so, how should I read
this statement? Does it matter to Rails what the index is called?
In “fk_items_product”, “items” is pluralized but “product” is not. Is
this because it is a one_to_many relationship? If so, how should I
read
this statement? Does it matter to Rails what the index is called?
I don’t believe the name of the index is significant, as I don’t believe
it’s ever referenced in Rails generated DML.
As far as how to read it, it reads to me as though it’s a foreign key
connecting one or more items to a single product, via:
You tell it your relationships in the model files, ie item.rb and
product.rb ,using the has_many, has_one, belongs_to relationship.
If you read more of that chapter, and I think before what you posted,
it mentions that RoR can’t really derive the relationship and it
provides an example why it would be difficult.
Also, have you tried any examples using differently named foreign keys
to see if it breaks anything?
I have the agile webdev book, and I didn’t find it. So what your saying
is
that the foreign key constraint is NOT a necessity?
(as long as your coding is good enough ofcourse …
Regards,
Gerard.
On Thursday 05 January 2006 22:23, Nic W. tried to type something
like:
to see if it breaks anything?
index is significant. On the above mentioned page, this line is shown in
Naming of indexes should never make any difference to SQL, however it’s
generated (by Rails, by Hibernate, by human fingers). It’s the SQL
optimizer’s job to figure out what index to use, not the SQL
programmer’s.
You could number your indices from FK_1 to FK_100000, and it wouldn’t
make a
difference to any of your SQL. I’ve worked places that did indeed do
that,
at least per table. The name of the index is only important in DDL -
creating , or otherwise managing it - it never appears in DML.
So worry not.
“It’s worth noting that it isn’t the foreign key contraints that set up
the
relationships…” and goes on from there, a good 3-4 paragraphs on on
the
topic.
In short, what’s significant is column naming. Rails expects that the
name
of a column that’s a foreign key reference to ‘ADDRESSES’ will be named
‘ADDRESS_ID’ by default.
“:foreign_key - specify the foreign key used for the association. By
default
this is guessed to be the name of the associated class in lower-case and
“_id” suffixed. So a Person class that makes a
belongs_tohttp://api.rubyonrails.com/classes/ActiveRecord/Associations/ClassMethods.html#M000473association
to a
Boss class will use “boss_id” as the default foreign_key.”
Table naming and column naming, important. Index or constraint naming,
ignored.
Yes, as long as no one is going into the database through some other
tool
(Access) to modify data. Setting up referential integrity in the
database
provides some measure of data integrity at the lowest level. Even if
you’re
the DBA working on the data from vendor tools to modify data by hand
that an
app messed up, declared referential integrity can quite possibly keep
you
from accidentally sawing off your leg with a bad INSERT INTO, UPDATE or
DELETE query…
Having to go through a database (in the most generic sense of the term,
like
in a flat-file database system, Excel, etc) to look for orphaned child
items
is pretty dull and boring work that should be prevented at the lowest
levels
if possible. Relying on it solely in the application layer is…full of
a
little too much developer hubris, imho.
:foreign_key lets you override the expected relationship field name.
If
you’re working with a legacy database (i.e., one not set up wtih Rails
conventions), this is an important feature to be able to do this.
Table naming and column naming according to Rails conventions is very
nice,
but not necesarily important in all cases. Being able to ultimately
specify
things IS important (i.e., :foreign_key).
Index names are used by the database. While not obviously important to
the
Rails developer, some databases return the name of the index or
constraint,
and having meaningful names here makes it far easier to get to the
source of
the problems rather than decoding what “constraint system_005AF32
violated”
actually refers to, because they can get returned back into the Rails
app by
the database…
But this has to do with the naming of intended foreign key fields by
convention (overridable with the :foreign_key attribute). As far as any
relationships set up in the database, Rails doesn’t know about them. In
that
sense, they’re optional, but for most DBAs, they’re necessarily required
for
a variety of reasons, even if they’re not explicitly required in or used
by
an application framework like Rails.
I conclude: anything in the database concerning foreign keys are only
used by the database to ensure integrety. It has no bearing to RoR what
so ever.
Right?
Right. Rails ignores fk contraints, primarily because DHH considers
them to be “vile and reckless destroyers of coherence”. fk constraints
exist only to assist the paranoid (I myself am amongst their number).
The naming doesn’t matter to Rails, since it ignores the whole
constraint. It also doesn’t really matter to the db, it’s just
documentation.
For more on why rails uses the associations stuff in your models instead
of db constraints (and why I had to write a plugin to get fk constraints
into ActiveRecord migrations) see the DHH blog post here:
