Início / dba / Perguntas / 134335
Accepted
Jake Wilson
Asked: 2016-04-05 12:56:57 +0800 CST

Vale a pena fazer uma tabela DATE separada ou não?

  • 772

Se eu tiver uma tabela assim:

my_table
=======================
id    date    some_data

Faz algum sentido puxar datepara a sua própria mesa? O datecampo usaria o datetipo de dados. Então agora ficaria assim:

my_table
==========================
id    date_id    some_data

dates
==========
id    date

De acordo com o MySQL, datetipo de dados = 3 bytes. O date_idprecisaria ser um máximo de MEDIUMINT(3 bytes) para obter o mesmo resultado. Um normal INTou BIGINTexcede os requisitos de armazenamento de um DATEtipo.

Uma desvantagem de uma tabela separada é que as consultas seriam mais complicadas porque estou entrando em outra tabela.

Existem outras ramificações que precisam ser levadas em consideração quanto a dividir ou não o datecampo em sua própria tabela? Minha reação instintiva é que não vale a pena fazer isso, a menos que você esteja lidando com um pequeno conjunto de datas (pequeno o suficiente para usar TINYINTou SMALLINT).

mysql datatypes

2 respostas

  1. Best Answer

    Parece-me que é um exemplo clássico de pensar demais em seu design.

    Mantenha as datas na mesma tabela para que possam ser facilmente indexadas com outras colunas, se necessário, e não ocupem 3 vezes mais bytes e não tornem a vida um inferno para futuros desenvolvedores.

    • 8

  2. A normalização costuma ser uma boa ideia, seja por flexibilidade ou espaço. Mas normalizar valores "contínuos", como DATE, DATETIME, FLOAT, etc, geralmente é um erro. Não faça isso.

    Talvez o maior problema ocorra quando você decide filtrar um intervalo de datas e descobre que o JOINdesempenho está matando.

    Mesmo que você tenha menos de 255 datas (estou pensando em TINYINT UNSIGNED), DATEnão vale a pena virar um id.

    Já que estamos falando de ids, geralmente eles devem ser UNSIGNEDe NOT NULL. E quase nunca é BIGINTgarantido.

    • 2

relate perguntas