has_many relations and foreign keys

rubyonrails-talk
1

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.

2

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.

3

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.