Using a string column instead of an id column to differentiate records

How do you decide whether to use a string column or an id column to
differentiate between different types of records?

Suppose you have a relationships table that maps users to forums. The
possible relationships can be: subscriber, moderator, owner.

When does it make sense to move those relationship types to their own
table
and reference them through a relationship_type_id column? What’s the
criteria? Or is it better to use a string column to differentiate them?

On Feb 28, 2012, at 2:09 PM, Mohamad El-Husseini wrote:

How do you decide whether to use a string column or an id column to
differentiate between different types of records?

Suppose you have a relationships table that maps users to forums. The possible
relationships can be: subscriber, moderator, owner.

When does it make sense to move those relationship types to their own table and
reference them through a relationship_type_id column? What’s the criteria? Or is
it better to use a string column to differentiate them?

Does the client/admin want to be able to change the names or number of
these groups, or are you going to be updating it (and thus could make
these sorts of code-level changes) when the management winds change?

For a few options such as you have here, there’s no reason to do it,
IMO, since with an index, it’s going to be just as fast or faster than
joining another table by a numerical lookup. I would pull these options
out into a constant so you only have one place to type them, too.

Walter

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs