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.