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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On 2/26/07, Rm Rm <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > 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. > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 Ivers 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.-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On 2/26/07, Rm Rm <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > 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 Ivers 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. > > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 Ivers 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.-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. On 2/26/07, Rm Rm <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > 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 Ivers 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. > > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---