Forum: Ruby on Rails Naming convention for foreign keys

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jakob R. (Guest)
on 2006-01-05 20:30
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:

constraint fk_items_product foreign key (product_id) references
products(id)

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?

Thanks,

Jakob
Jakob R. (Guest)
on 2006-01-05 23:11
Hi,

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:
>
> constraint fk_items_product foreign key (product_id) references
> products(id)
>
> 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?
>
> Thanks,
>
> Jakob
Tom M. (Guest)
on 2006-01-05 23:24
(Received via mailing list)
On Jan 5, 2006, at 4:11 PM, Jakob R. wrote:

>> the example:
>>
>> constraint fk_items_product foreign key (product_id) references
>> products(id)
>>
>> 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:

items.product_id -> products.id

Seems pretty coherent.

--
-- Tom M.
Nic W. (Guest)
on 2006-01-05 23:24
(Received via mailing list)
Rails doesn't care.

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?

- Nic.

On 1/5/06, Jakob R. <removed_email_address@domain.invalid> wrote:
> products(id)
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
- Nic
Nicolai R. (Guest)
on 2006-01-05 23:24
(Received via mailing list)
Jakob R. schrieb:
> Hi,
>
> Please - somebody must know the answer to this one.
>
> Jakob
>

According to the documentation
(http://wiki.rubyonrails.com/rails/pages/NamingConventions) it is - and
I quote:

When joining two tables, the foreign ID must be in the format:
[tablename]_id.

Where tablename is the singular form of the tablename.
Gerard (Guest)
on 2006-01-05 23:33
(Received via mailing list)
Nic,

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
> >
> - Nic
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails

--
"Who cares if it doesn't do anything?  It was made with our new
Triple-Iso-Bifurcated-Krypton-Gate-MOS process ..."

My $Grtz =~ Gerard;
~
:wq!
Skott Klebe (Guest)
on 2006-01-05 23:39
(Received via mailing list)
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.

Skott Klebe
Jakob R. (Guest)
on 2006-01-05 23:45
Hi all,

Thanks for your answers.

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?

Jakob
Tom M. (Guest)
on 2006-01-06 00:30
(Received via mailing list)
On Jan 5, 2006, at 4:45 PM, Jakob R. wrote:

> I conclude: anything in the database concerning foreign keys are only
> used by the database to ensure integrety.

No, that's not what was said.

Your question in your original post was answered, not the gigantic
generalization offered above. :-)

column names for both primary and foreigns key columns do matter so the
answer to the generalized questions above are:

> It has no bearing to RoR what so ever.

No!

and:

> Right?

Wrong!

It's the naming of the foreign key constraint that does not matter.

--
-- Tom M.
Skott Klebe (Guest)
on 2006-01-06 01:40
(Received via mailing list)
Sorry, I think I misunderstood your question.

Take a look at Active Web D. with Rails, pg226.

"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_.
>From the doc:
http://api.rubyonrails.com/classes/ActiveRecord/As...

":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_to<http://api.rubyonrails.com/classes/ActiveRecord/As...
to a
Boss class will use "boss_id" as the default foreign_key."

Table naming and column naming, important.  Index or constraint naming,
ignored.

Hope this settles it for you.

SK
Corey L. (Guest)
on 2006-01-06 19:21
(Received via mailing list)
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.
Corey L. (Guest)
on 2006-01-06 19:27
(Received via mailing list)
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.
Corey L. (Guest)
on 2006-01-06 19:33
(Received via mailing list)
: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...
Alan F. (Guest)
on 2006-01-07 01:33
> 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:

http://www.loudthinking.com/arc/000516.html

A.
This topic is locked and can not be replied to.