Ruby on Rails database using static lookup tables or constant strings

Question

In some ruby on rails projects, I have seen instances where strings are used instead of a foreign key reference to a lookup table.

I usually code in C#/SQL Server and use lookup tables, but am not particularly experienced in ruby on rails.

So my question is, should I be using strings instead of lookup tables in my ruby on rails web project (mysql and active record)? Is this something specific to ruby on rails, or to dynamically typed languages? Or for some particular circumstances? Or is it just bad database design?

By lookup tables I mean, like the following

UserStatus

Id    Name
1     Active
2     Disabled

User

Id    Username               UserStatusId
1     [email protected]   1
1     [email protected]   2

Whereas with just strings

User

Id    Username               UserStatus
1     [email protected]   active
1     [email protected]   disabled

Answer 1

[EDIT] Ruby on Rails 4 enums

Rails 4 supports enums, so you can declare an enum attribute where the values map to integers in the database, but can be queried by name.

class Conversation < ActiveRecord::Base
  enum status: [ :active, :archived ]
end

conversation.archived!
conversation.active? # => false
conversation.status  # => "archived"

Conversation.archived # => Relation for all archived Conversations

Conversation.statuses # => { "active" => 0, "archived" => 1 }

---

Rails 3 and older

You could implement something like this:

USER_STATUS_VALUES = { 1 => :active, 2 => :disabled }

class UserStatus
  attr_reader :status_id

  def status
    USER_STATUS_VALUES[@status_id]
  end

  def status=(new_value)
    @status_id = USER_STATUS_VALUES.invert[new_value]
    new_value
  end
end

You would use it like this:

my_status = UserStatus.new

my_status.status = :new
puts "status: #{my_status.status}"
puts "status_id: #{my_status.status_id}"

Will return:

status: new

status_id: 1

Note: I could have used 'active' instead of :active but in this case, use of symbols is more appropriate.

Answer 2

should I be using strings instead of lookup tables in my ruby on rails web project (mysql and active record)?

I usually try to avoid lookup tables in my ruby on rails projects. Instead, I tend to store the user representations in the language files, e.g.:

user:
  status: Status        
  status_values:
    1: Active
    2: Disabled

(Or whatever kind of structure you prefer, I am not religious about this.)

Then, in the model file, I only introduce Ruby constants for those values that I actually reference in Ruby code:

class User 
    ...
    STATUS_ACTIVE = 1

    def active?
      self.status == User::STATUS_ACTIVE
    end
end

Here as well, I am not religious about this particular syntax. If you feel like it, you could hide some of these lines with meta-programming. The letters "a-c-t-i-v-e" show up awfully often, so some guys may prefer a more DRY approach. ;)

Is this something specific to ruby on rails, or to dynamically typed languages?

No, I have seen both variants (lookup tables vs. hardcoded enumerations) in all kinds of languages.

Or for some particular circumstances?

This is more like it. For example, if you have an application with a significant chance that these values would change over time; or if you have a multi-language application, it would be crazy to always have to go back to the code to change anything.

But there are definitely cases where it would not make any sense at all to change these lookup tables without also changing the code. In this example, the code presumably has to know when a user is active or not active; i.e., it would not make sense to have some translator nilly-willy add a third value 3: maybe-active without modifying the code to actually implement some behaviour. In this case, having a separate table USER_STATUS would be useless.

In short: if "some guy" should be able to modify these values at any point of time, this is much easier in the DB (maybe with an admin "self-service" functionality in your application). Then, these lookups are proper data of your application. Obviously, some values are obvious candidates for a DB (for example, a list of all ISO country codes in all their variants).

Or is it just bad database design?

Not per se, as shown above.

Answer 3

You can also use the ActiveHash Gem to create a static Model from a YAML/JSON file.