Banco de dados Ruby on Rails usando tabelas de pesquisa estática ou cadeias de caracteres constantes

[EDITAR] Ruby on Rails 4 enums

O Rails 4 suporta enums, então você pode declarar um atributo enum onde os valores mapeiam para inteiros no banco de dados, mas podem ser consultados pelo nome.

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 e mais antigos

Você poderia implementar algo assim:

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

Você usaria assim:

my_status = UserStatus.new

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

retornará:

status: new

status_id: 1

Nota: Eu poderia ter usado 'active' em vez de :active , mas neste caso, o uso de símbolos é mais apropriado.

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

Eu costumo tentar evitar tabelas de pesquisa em meus projetos ruby on rails. Em vez disso, tenho a tendência de armazenar as representações do usuário nos arquivos de idioma, por exemplo:

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

(ou qualquer tipo de estrutura que você preferir, eu não sou religioso sobre isso.)

Então, no arquivo de modelo, eu só introduzo constantes do Ruby para aqueles valores que eu realmente referenciei no código Ruby:

class User 
    ...
    STATUS_ACTIVE = 1

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

Aqui também, eu não sou religioso sobre esta sintaxe particular. Se você quiser, pode esconder algumas dessas linhas com a meta-programação. As letras "a-c-t-i-v-e" aparecem com muita freqüência, então alguns caras podem preferir uma abordagem mais seca. ;)

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

Não, eu vi as duas variantes (tabelas de pesquisa versus enumerações codificadas) em todos os tipos de idiomas.

Or for some particular circumstances?

Isso é mais parecido com isso. Por exemplo, se você tiver um aplicativo com uma chance significativa de que esses valores mudem com o tempo; ou se você tiver um aplicativo em vários idiomas, seria loucura sempre ter que voltar ao código para alterar qualquer coisa.

Mas definitivamente há casos em que não faria sentido alterar essas tabelas de consulta sem alterar o código. Neste exemplo, o código presumivelmente tem que saber quando um usuário está ativo ou não ativo; ou seja, não faria sentido ter algum tradutor adicionando um terceiro valor 3: maybe-active sem modificar o código para realmente implementar algum comportamento. Neste caso, ter uma tabela separada USER_STATUS seria inútil.

Resumindo: se "algum indivíduo" puder modificar esses valores a qualquer momento, isso é muito mais fácil no banco de dados (talvez com uma funcionalidade de "autoatendimento" do administrador em seu aplicativo). Então, essas pesquisas são dados adequados do seu aplicativo. Obviamente, alguns valores são candidatos óbvios para um banco de dados (por exemplo, uma lista de todos os códigos de países ISO em todas as suas variantes).

Or is it just bad database design?

Não per se, como mostrado acima.

Você também pode usar a ActiveHash Gem para criar um modelo estático a partir de um arquivo YAML / JSON.