On 13 July 2016 at 16:45, Johnny Stewart <lists@ruby-forum.com> wrote:
> Colin Law wrote in post #1184606:
>> On 13 July 2016 at 16:14, Johnny Stewart <lists@ruby-forum.com> 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."
Agreed if there are "many different data fields". As is always the
case I advise using the KISS principle. Do it the easy way first
(easy code has fewer lines and therefore fewer bugs) and only if
proven necessary then add complexity to improve efficiency. Nine
times out of ten (probably more) it will not be necessary.
Possibly an even better solution to the OPs problem would be to use
roles for different user types and not even have the complexity of
STI. It depends how much role specific data and behaviour there is.
My advice would be to start with just roles and move to STI if
necessary.
Colin
--
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 rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CAL%3D0gLvkW7YWiFnhWv6M_AmWxL9CaHWpWVC1UZrZMAR-%3D%3DYvLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment