Are you using foreign keys?

Hi Guys,

When you use ActiveRecord relationship, there is always a place to put
foreign key on your table, e.g., id and foo_id. However, from rails
perspective, foreign keys are not required as long as data could be
associated.

I would like know your design decision on database foreign keys. Is
it better to have it? Or just leave it to speed up your development?

Thanks,
Glenn

Glenn wrote:

Hi Guys,

When you use ActiveRecord relationship, there is always a place to put
foreign key on your table, e.g., id and foo_id. However, from rails
perspective, foreign keys are not required as long as data could be
associated.

I would like know your design decision on database foreign keys. Is
it better to have it? Or just leave it to speed up your development?

Thanks,
Glenn

Glenn,

Are you referring to “foreign keys” or “foreign key constraints”? The
former is certainly needed by ActiveRecord/Rails for any non trivial
relationship between 2 tables. Leaving out foreign keys is not even an
option when working with relational entities.

Perhaps you meant foreign key constraints? Currently, their use
requires that you know vendor specific details of your db (which is not
usually a concern for most). Anyways, in my opinion, you are right in
that you can usually omit them until your DBA comes back from vacation
or you wake up in a pool of sweat knowing that you could have done more
to protect the integrity of your data.

HtH

ilan

El Jul 27, 2007, a las 9:06 PM, Glenn
escribió:

I would like know your design decision on database foreign keys. Is
it better to have it? Or just leave it to speed up your development?

I normally use them via this plugin:

http://www.redhillonrails.org/#foreign_key_migrations

You get indices as a side-effect (don’t know whether that applies to
all databases) and they help getting your :dependents right in has_*
declarations.

– fxn

Hi Everyone,

Thank you very much for your postings. It really helped me to start a
new project.

Ilan, Thanks for your clarification of the terminology. Yes, I was
wondering if foreign key constrain should be defined on database
level.

As Josh pointed, it we can check referential integrity on application
level. We used to use database for everything such as managing
transaction, validating data, user authentication, etc. However, it
appears that current trend is to put most staff in application level
and let database to take care persistence only. My work place still
have lots of legacy applications sitting top of of the database. It
would be good idea to have constrains in both application and
database.

Xavier, thank you so much for showing me a nice plugin. I will
definatelly look into the plugin. It’s will be very nice to have
automated solution for creating foreign key constrains.

Glenn

Ilan B. wrote:

Glenn wrote:

When you use ActiveRecord relationship, there is always a place to put
foreign key on your table, e.g., id and foo_id. However, from rails
perspective, foreign keys are not required as long as data could be
associated.

I would like know your design decision on database foreign keys. Is
it better to have it? Or just leave it to speed up your development?

Are you referring to “foreign keys” or “foreign key constraints”? The
former is certainly needed by ActiveRecord/Rails for any non trivial
relationship between 2 tables. Leaving out foreign keys is not even an
option when working with relational entities.

Perhaps you meant foreign key constraints? Currently, their use
requires that you know vendor specific details of your db (which is not
usually a concern for most). Anyways, in my opinion, you are right in
that you can usually omit them until your DBA comes back from vacation
or you wake up in a pool of sweat knowing that you could have done more
to protect the integrity of your data.

If you want some level of integrity but don’t want to stick the
constraints in the DB, you could use this:

http://blog.hasmanythrough.com/2007/7/14/validate-your-existence

It does something pretty close to fk constraints using Rails
validations.


Josh S.
http://blog.hasmanythrough.com