Colin Law wrote in post #1184606: > On 13 July 2016 at 16:14, Johnny Stewart <[email protected]> wrote: >>>> So, you don't need to keep all the chef or athlete data in the user >> only has to handle registrations etc. I don't think there is any need to >> hold data pertaining to that user being a chef. >> >> All it needs is maybe profile name, email address, password etc. That >> needn't change here. >> >> Using STI we store that one extra column of type - then use that to >> see what table that user's extra info is held in (chef_info, >> athlete_info etc). > > I do not believe that is the usual use case for STI. See [0] for a > good description of the use of STI. > > Colin > > [0] > http://eewang.github.io/blog/2013/03/12/how-and-when-to-use-single-table-inheritance-in-rails/ > > Colin
Hi Colin, Maybe not, however, I still think adding in a lot of nullable columns into the User table when they don't need to be there doesn't make sense. >From the blog post you cite above: "If sub-classes that you intend to use for STI have many different data fields, then including them all in the same table would result in a lot of null values and make it difficult to scale over time." So, I think that there is no real need to have things like food-speciality and training-ground-address in the User table. These are better moved into other tables. Also - as regards the OP it removes the need to bring in polymorphism and messing about with Devise's registrations controller. J. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/0b247a1b501b87381b75acfeecc1c2db%40ruby-forum.com. For more options, visit https://groups.google.com/d/optout.
