I’m trying to find the “Rails way” of modeling users of my
application. Traditionally, I’d have a “users” table with common
information, along with “students” and “teachers” tables. For login
purposes, I’d only be concerned with the users table. (Classic class
table inheritance, basically.)
Since Rails supports single table inheritance, how would the Rails
gurus model this app? Is it really best to just throw everyone into
one “users” table, and have a load of columns on it?
Personally I would go with polymorphic associations. Essentially, define
one table with all shared attributes (the users table) and then apply
polymorphic associations to tie it with the specific teachers / students
table.
I thought about that, but then wasn’t crazy about:
t = Teacher.find(3)
t.user.last_name
I’m not sure if you could let Teacher < User and User <
ActiveRecord::Base, since you’d be applying the polymorphic to it? I
apologize if this would be an easy task, I’m trying to come to the
Ruby world from a history of static languages.
On Feb 1, 11:30 pm, Nathan E. <rails-mailing-l…@andreas-
I hadn’t thought about delegating it to the polymorphic association.
My main reason for leaning away from STI is that I will likely have a
good deal of columns for both Students and for Teachers that aren’t
applicable to the other. Additionally, storing students and teachers
and in the same table just feels wrong, since they’re so fundamentally
different.
On the plus side of STI, I can use one query and store the
current_user for the request, and have access to all the applicable
properties. I’m on the fence, but will read up more on Rails’
polymorphic associations.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
