Por que o mysql inverte a data?

Quando começamos a trabalhar com MySQL, principalmente no começo da carreira, tem uma coisa que causa imediata estranheza: a maneira que o MySQL armazena datas. Tomemos o dia 29/02/2020 como exemplo. Quando você escrever aquele código esperto para salvar essa data, deverá fazer a conversão para este formato 2020-02-29 (yyyy-mm-dd). Uma coisa interessante – e que pode lhe dar várias ideias no futuro – é pensar o porque o MySQL foi implementado desta maneira. A explicação é muito simples. Imagine que você vai comparar duas datas em sua aplicação para saber qual é a mais recente e escreve o pseudo-código abaixo. Vou considerar que em nossa pseudo-linguagem temos funções que facilitam trabalhar com elementos de datas.

Data1 = '29/02/2020';
Data2 = '25/12/2019';

IF (Data1.ano == Data2.ano)
    IF (Data1.mes == Data2.mes)
    [...]
ELSE IF (Data1.ano > Data2.ano)
    PRINT Data1 . ' é mais recente que ' . Data2
ELSE
    PRINT Data2 . ' é mais recente que ' . Data1

O bloco marcado com […] seria uma repetição da estrutura do bloco externo testando o mês e dentro dele mais uma repetição desta estrutura testando o dia. Veja quanto código para testar uma simples data. “Ah, mas a linguagem de programação que eu uso já tem funções nativas para comparar datas, algo como DATEDIFF”. Todavia, estamos pensando no armazenamento, o porquê daquele formato ser eficiente.

Lembremos daquela primeira data que falamos, armazenada invertida e agora convertida para um número inteiro:

’29/02/2020′ => ‘2020-02-29’ => 20200229

Ou seja: 20.200.229 (Vinte milhões, duzentos mil e duzentos e vinte e nove)

Então para a comparação se 29/02/2020 é mais recente que 25/12/2019 teríamos:

20200229 > 20191225

Ficou fácil agora de entender, trocamos uma operação complicada de vários testes e tal por uma comparação entre dois números inteiros. Com certeza uma operação mais eficiente.

Vale lembrar, antes e você sair trocando tudo por números inteiros, que ganhamos com uma mão e perdemos com a outra. Algumas vezes a conversão em inteiros gera problemas, como por exemplo, quando salvamos um CPF que começa com 0 e o banco perde esse dígito.

012.345.678-90 seria salvo como 1234567890

Isso pode dar erros em consultas fazendo o CPF não ser encontrado. Nesse momento você lembra que não se faz conta com CPF, você não precisa saber se um é maior que o outro, então manter como string não tem problema nesse caso. Tudo é ponderação. Espero que estes exemplos sirvam para aguçar sua imaginação quando estiver pensando sobre maneiras – mirabolantes ou não – de armazenar dados.

Publicado por

Murilo Freire

Formado em Análise de Sistemas, MBA em Gestão de Projetos, Mestrado em Biotecnologia e Doutorado - em curso - em Biotecnologia. Programei do Delphi ao PHP passando pelo Unity 3D, sempre fascinado por programação mas também por cultura pop, jogos (eletrônicos e de tabuleiro), aleatoriedades, Cabala, Tarô e bruxaria.

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.