Estou trabalhando em um diagrama de banco de dados e tenho uma tabela chamada cm_identifier_type
. Cada registro desta tabela pode ter ou não um arquivo para download (salvo um caminho de arquivo). Identifiquei duas maneiras possíveis de conseguir isso.
- Coloque uma coluna
download_file
comoVARCHAR(250)
e defina comoNULL
padrão (isso porque nem todos os registros terão um download relacionado)
- Crie uma relação entre
cm_identifier_type
e uma nova tabelacm_download_file
:
Agora, em relação ao desempenho, economia de espaço em disco, economia de consulta e assim por diante, como você faria isso? Qual é a sua recomendação sobre este caso extremo?
Nota: no momento estou usando MariaDB 10.1.x, mas isso será em uma instância do MySQL, provavelmente 5.x ou mais, não tenho certeza, pois ainda não tenho esses detalhes
Se você tiver muitas estatísticas específicas sobre a frequência com que suas colunas opcionais serão nulas e com que frequência as colunas não nulas precisam ser lidas (em oposição às colunas principais e obrigatórias), você poderá calcular a economia de espaço (ou não) e no mínimo, você poderia derivar alguns experimentos de desempenho para testar cada abordagem.
Não existe uma regra prática sobre se é "melhor" segregar colunas opcionais em uma tabela separada.
"Melhor" é um termo subjetivo. O que tem valor? Espaço em disco, ciclos de CPU, tempos de resposta de consulta, simplicidade de código? Você não pode considerar os méritos relativos de uma abordagem em detrimento de outra sem primeiro considerar o que está tentando otimizar.
Existem vários motivos pelos quais você pode querer mover colunas opcionais para uma subtabela relacionada 1:1 separada. Veja minha resposta a esta pergunta para mais discussões sobre esses motivos.
No seu caso, como você está preocupado com o espaço, precisa ter em mente algumas coisas sobre como os dados são armazenados fisicamente:
Há muitas influências concorrentes sobre qual ocupa menos espaço e qual tem melhor desempenho. Você precisa considerar:
Outra coisa a considerar, talvez até a coisa mais importante a considerar, é se você está pensando demais no problema ao tentar pré-otimizar. O disco é muito barato. CPU é muito barato. Programadores são caros. A menos que você precise se preocupar com escala massiva, talvez a melhor resposta seja aquela que deixa você com o código mais simples (com menos bugs, mais fácil de manter).
Acho que a melhor opção é a primeira solução, já que o campo é um VARCHAR: isso significa que nenhum espaço significativo é ocupado se o valor for NULL.
Por outro lado, com a segunda solução você tem uma tabela a mais para manter, outros índices, precisa juntar se precisar do valor, etc. Muita trabalheira para um problema que pode ser resolvido de forma bem simples.