Forum: Ruby on Rails has_many relations and 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.
Rm R. (Guest)
on 2007-02-26 22:27
Hi,

I am still new to RoR, and I have a doubt about foreign keys. Our
database has all the relationships defined at the table levels using
foreign keys. So, now how can relationships defined in RoR help me in
making my application better. Our application was initially in java and
we are moving to RoR, hence I want to know that do I need to change our
data model also ?

Thanks.
Luke I. (Guest)
on 2007-02-26 22:56
(Received via mailing list)
You don't have to change anything.  But, consider that FK support in
Rails
isn't particularly amazing and fantastic... a lot of times, getting your
foreign keys to work well with everything else you're doing in Rails can
invovle some intense hacking (especially when using the testing
features).

For the most part, the associations that you can define via ActiveRecord
in
Rails invalidate the use of foreign keys... they do exactly the same
thing
as foreign keys do, and they do it in a more intelligible and
easy-to-consume manner.  That being said, if your data's integrity is
absolutely 100% vital in all cases (ie you are a medical institution, or
a
bank, or some such), I'd say stick with your foreign keys, because they
can't be skipped by the program (and Rails has stuff built in to skip
almost
any functionality it implements).

It's definitely something you need to think about very carefully before
deciding which way to move forward... if you can be more specific about
your
particular situation, then others who know more about this stuff might
be
able to provide you with some more specific help.
Rm R. (Guest)
on 2007-02-26 22:59
Till now, in beta version that we are working on, we have not used the
rails foreign keys at all. All the checks are done in the code itself.
But I was wondering if we are doing the right thing?



Luke I. wrote:
> You don't have to change anything.  But, consider that FK support in
> Rails
> isn't particularly amazing and fantastic... a lot of times, getting your
> foreign keys to work well with everything else you're doing in Rails can
> invovle some intense hacking (especially when using the testing
> features).
>
> For the most part, the associations that you can define via ActiveRecord
> in
> Rails invalidate the use of foreign keys... they do exactly the same
> thing
> as foreign keys do, and they do it in a more intelligible and
> easy-to-consume manner.  That being said, if your data's integrity is
> absolutely 100% vital in all cases (ie you are a medical institution, or
> a
> bank, or some such), I'd say stick with your foreign keys, because they
> can't be skipped by the program (and Rails has stuff built in to skip
> almost
> any functionality it implements).
>
> It's definitely something you need to think about very carefully before
> deciding which way to move forward... if you can be more specific about
> your
> particular situation, then others who know more about this stuff might
> be
> able to provide you with some more specific help.
Luke I. (Guest)
on 2007-02-26 23:05
(Received via mailing list)
It depends on what you define as "the right thing".
If you're talking about ease of code, functionality, etc... then go with
the
stuff built into Rails.
If, like I said before, you require 100% absolute data integrity no
matter
what (ie. a failure to maintain data integrity would result in
catastrophic
results), I would go with the database foreign keys: they are closer to
the
actual writing of the data to the DB, and thus are much harder to pass
by
than the Rails stuff.
Rm R. (Guest)
on 2007-02-26 23:11
Another factor is that the same db will be accessed by the part of
application which will remain in java and can't be ported to ruby
because of 3rd party apis needed to do some backend stuff.

I was just wondering that in this case how can RoR featues help me in
improving my application.


Luke I. wrote:
> It depends on what you define as "the right thing".
> If you're talking about ease of code, functionality, etc... then go with
> the
> stuff built into Rails.
> If, like I said before, you require 100% absolute data integrity no
> matter
> what (ie. a failure to maintain data integrity would result in
> catastrophic
> results), I would go with the database foreign keys: they are closer to
> the
> actual writing of the data to the DB, and thus are much harder to pass
> by
> than the Rails stuff.
Luke I. (Guest)
on 2007-02-26 23:20
(Received via mailing list)
In that particular case, I would absolutely stay with the database level
foreign keys: Java can't take advantage of whatever it is you're doing
in
Rails, so you'd lose any advantages of using Rails stuff right off the
bat.

If you absolutely must keep that Java piece, then stick with the DB FKs.
This topic is locked and can not be replied to.