Eficiência em banco de dados
comentada em 11/02/2021 11:33

É uma chave estrangeira ou apenas uma coluna que contém os valores de uma enumeração?

@Norton92

performance - SQL SELECT speed int vs varchar - Stack Overflow

Em resumo INT é um tipo mais eficiente que o VARCHAR por ocupar menos espaço em memória.

Você pode criar por exemplo pra ser IDENTITY 1,1 (começa em 1 e vai sendo incrementado em 1 a cada inserção), mas aí fica ao gosto do freguês.

Se mesmo assim ficar lento (caso seja na casa de milhões de consultas/dia) da sempre pra usar um índice, só cuidado na utilização do índice que em alguns casos fica mais lento, tem que avaliar com calma, caso precise usar.

Se você for pensar apenas na questão de eficiência, é muito mais lógico inferir que um tipo numérico teria um desempenho melhor, até porque é muito mais simples representar e armazenar um número do que um texto, computacionalmente falando.

Porém tem que parar pra pensar em outras coisas também. Quando se desenvolve software a performance é apenas [mais] uma das características que o desenvolvedor tem que levar em conta. Muitas das vezes existe um trade-off entre desempenho e outras necessidades. Você tem que ponderar se a otimização que está tentando aplicar realmente trás algum benefício. Esse sistema será utilizado em larga escala e por vários usuários, de forma que qualquer otimização seja bem-vinda? Será que o ganho de desempenho não representa mais complexidade? 

No seu caso, se optar por utilizar tipo numérico, vai ter que garantir a consistência do dado via código, não pelo banco. Por exemplo, em um e-commerce onde o tipo 1 representa a categoria 'Eletrônicos' e tipo 2 representa 'Livros', você tem que garantir que 1 seja realmente eletrônicos sempre e 2 seja livros sempre. Isso no código, porque no banco é apenas um número, não representa nada por si só.

Particularmente eu utilizaria texto porque acho que o ganho não deve ser tão grande assim, pelo menos falando de sistemas onde otimizações nesse nível não fazem grande diferença. 

@aronnax tem razão, tem que levar em conta diversos fatores, como ele não deu detalhes pensei no mais eficiente, mas não necessariamente INT é o melhor, como tudo na vida, depende de cada caso.

@aronnax concordo com sua ponderação

Esta preocupação poderia ser um caso de "otimização prematura" já discutida por Donald Knuth no livro "The Art of Computer Programming"

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

Pode armazenar como INT desde que use enumerators na sua aplicação: enum in Python - GeeksforGeeks

Mas se você sempre for buscar pelo texto completo não vejo problema em armazenar como texto e criar um index.

TL;DR: se a lista tem a possiblidade de mudar (o que parece já que 40 é muita coisa e alguém pode querer aumentar ou agrupar), eu usaria uma outra tabela e salvaria o inteiro da chave estrangeiro. Senão meio que tanto faz.


Resposta:

Assumindo que esses possíveis 40 valores sejam os "tipos enumerados" ou "opções possíveis" eu colocaria isso em uma outra tabela e armazenaria o inteiro na sua tabela em questão.

 

Por exemplo, se esses valores fossem os estados do Brasil. Eu teria SP, MG, etc em uma outra tabela e salvaria o identificador 1 ou 2 na tabela que estivesse indicando qual estado está usando.

 

Mas eu faria isso por uma questão de praticidade. De poder manter um conjunto fechado dos valores possíveis (integridade referencial) e para facilitar adicionar novos tipos. Mas não pensaria em "performance", "quantidade de bytes"... provavelmente é irrelevante. Você precisa de petabytes de informação pra se preocupar com esse tipo de coisa.

 

Mas dito isso, talvez especificamente no caso de estados do brasil, estado civil, condição de um produto ("novo" ou "usado") e outras coisas que quase nunca mudam, não seria um absurdo manter como String desde que vc tenha uma forte validação.

Valeu pelas respostas galera. Acho que vou deixar o problema acontecer, isso se acontecer. Ai tento resolver, vou seguir com VARCHAR mesmo. 

@Norton92

Uma outra ferramenta que pode ajudar esclarecer um pouco mais de como as consultas se comportarão, é vc executar o plano de execução na sua consulta (comando explain plan no caso do Oracle). Com isso vc vai ver qual é o caminho que o banco vai fazer para retornar a consulta.

Vão ser apresentados dados como, se usa os índices para buscar na coluna, vai ver se ele faz full scan na tabela, quanto tempo gasto em cada passo, etc.

Aí sim talvez encontrar um possível ponto de otimização.

Maneiro, vou ver depois, não sabia disso. Descobri que o que eu uso (Postgres) tem também. 

Particularmente, eu separaria. 40 tipos diferentes é muita coisa, e outra, acho mais fácil de manter, mais fácil de analisar consultas posteriores e o mais importante, como já citado, se precisar de desempenho, coloca o índice porque a tabela já está separada. Em sistemas comuns acho que vale a pena não abrir mão de uma boa normalização. E separar nesse caso é um exemplo. Outra coisa que muitos não param para refletir é que a normalização facilita na passagem de conhecimento ou revisão sobre regras de negócio do sistema. Acredito ser fundamental para manutenção do sistema conhecer bem o que ele faz ao longo do tempo.

@Norton92 se a string não for grande, você pode manter como string mesmo.
Daí você cria um índice nessa coluna.

O que o banco vai fazer? Vai manter esses 40 itens em memória apontando para os dados a que eles se referem.

Não faz diferença nesse caso ser string ou inteiro.

Não gosto muito de "inventar" dado para otimizar sistemas. Você coloca complexidade desnecessária no seu projeto em troca de um "maior desempenho" bastante questionável.

O limite aqui é o tamanho da string.

Strings grandes podem não funcionar pra formar índices, nem chaves primárias, secundárias etc.

O banco vai usar esses 40 tipos diferentes somente para filtro. Por exemplo, quero somente do tipo "casa", então vai filtrar somente os que tiverem esse campo, e junto terão outros filtros que o usuário vai poder inserir para ser mais específico ainda.

Dá uma estudada em Normalização de Dados que vai clarear um pouco o que vc deve fazer.

Nesse caso eu utilizaria a mesma solução proposta pelo @MrBig .