Início / dba / Perguntas / 124936
Accepted
ReynierPM
Asked: 2016-01-01 07:27:20 +0800 CST

Qual é a melhor maneira de diagramar essa "relação" procurando desempenho e | ou economia de espaço em disco

  • 772

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_filecomo VARCHAR(250)e defina como NULLpadrão (isso porque nem todos os registros terão um download relacionado)

insira a descrição da imagem aqui

  • Crie uma relação entre cm_identifier_typee uma nova tabela cm_download_file:

insira a descrição da imagem aqui

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

mysql database-design

2 respostas

  1. Best Answer

    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:

    • Strings de tamanho variável não ocupam muito espaço se estiverem vazias.
    • Cada coluna anulável precisa de um bit para indicar se é nula ou não.
    • Uma tabela separada com colunas opcionais precisa armazenar a chave primária da tabela principal novamente (como uma chave estrangeira) e pode haver um índice separado nesta coluna também.

    Há muitas influências concorrentes sobre qual ocupa menos espaço e qual tem melhor desempenho. Você precisa considerar:

    • Com que frequência os dados opcionais vão faltar? Se for realmente raro, talvez você economize espaço segregando-o.
    • Com que frequência você precisa ler os dados opcionais? Se você lê sempre (esteja lá ou não), então talvez juntar-se a ele o tempo todo seja menos eficiente.
    • Por outro lado, se não estiver lá com muita frequência e se você quase nunca o ler, mesmo quando estiver, talvez seja mais eficiente ler registros mais curtos contendo apenas as colunas obrigatórias?

    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).

    • 5

  2. 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.

    • 1

relate perguntas