Naming Conventions for Associations


#1

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


#2

On Thu, Mar 26, 2009 at 8:29 AM, David T. removed_email_address@domain.invalid 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/


#3

Greg D. wrote:

On Thu, Mar 26, 2009 at 8:29 AM, David T. removed_email_address@domain.invalid 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.


#4

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!