Naming Conventions for Associations

Hi Everyone,

I seem to continually have this internal debate on how I should
approach naming certain associations on models. For example, let’s
say I have a User model and a User has one Status. Although, let’s
also say that in my system that ‘Status’ would be ambiguous with other
types of statuses, so I want to name the model UserStatus. The
problem that I face now, is that when I say a user has one UserStatus,
the way I would refer to the associated model would, by default, look
like:

@user.user_status

I feel that in this context, the double ‘user’ references are
redundant. Something like this would be more natural:

@user.status (where status is UserStatus)

I realize that I can achieve the second syntax in a couple of ways.
In the User model, I can change the association name, like:

belongs_to :status, :class_name => ‘UserStatus’, :foreign_key =>
‘user_status_id’

This works, but it creates the getters/setters:

@user.status
@user.user_status_id

I would expect for it to also let me change the id through something
like @user.status_id, not @user.user_status_id. So, this only cleans
things up half-way.

I realize too, that I can rename the actual database foreign key to
status_id instead of user_status_id, and then do something like this
in my user model:

belongs_to :status, :class_name => ‘UserStatus’

This let’s me access the status and status_id setters/getters as I
would expect. The thing about both of these changes though is that I
feel like I’m straying from the conventions, which I really want to
try to avoid. I wanted to get a survey of how other people usually
approach this. Any advice with this would be appreciated.

Thanks,
David

On Thu, Mar 26, 2009 at 8:29 AM, David T. [email protected] wrote:

I seem to continually have this internal debate on how I should
approach naming certain associations on models. For example, let’s
say I have a User model and a User has one Status. Although, let’s
also say that in my system that ‘Status’ would be ambiguous with other
types of statuses, so I want to name the model UserStatus. The
problem that I face now, is that when I say a user has one UserStatus,
the way I would refer to the associated model would, by default, look
like:

Sounds like you want a polymorphic association.

http://wiki.rubyonrails.org/howtos/db-relationships/polymorphic


Greg D.
http://destiney.com/

Greg D. wrote:

On Thu, Mar 26, 2009 at 8:29 AM, David T. [email protected] wrote:

I seem to continually have this internal debate on how I should
approach naming certain associations on models. �For example, let’s
say I have a User model and a User has one Status. �Although, let’s
also say that in my system that ‘Status’ would be ambiguous with other
types of statuses, so I want to name the model UserStatus. �The
problem that I face now, is that when I say a user has one UserStatus,
the way I would refer to the associated model would, by default, look
like:

Sounds like you want a polymorphic association.

If it were me, I would also consider whether a status warrants a
separate model in the first place. I would consider managing a user’s
status using a “finite state machine” design pattern.

Of course, it’s entirely possible that your design does warrant a
separate UserStatus model, but the generic nature of Status leads me to
think maybe it doesn’t. I’m just saying that sometimes de-normalizing a
database schema can greatly simplify the system design. And in some
cases even increase system’s performance.

Thank you both for your suggestions. For one reason or another, these
options didn’t occur to me originally in this situation, even though I
was familiar with both. Both make a lot of sense – you’ve given me a
lot to think about for now. Thanks!