Armazenando datas de uma outra forma
Esse artigo vai explicar uma forma alternativa de se armazenar datas em banco de dados. Não é uma novidade, aliás isso é coisa da galera da "old school", o pessoal que trabalhava com grande porte e coisas assim. Mas essa técnica não morreu, é bem interessante para se ter mais uma carta na manga.
Eu e as datas...
Apesar dos meus 25 anos (minha idade quando esse artigo foi
publicado), acho que tenho um pouco de experiência como
programador, já com 15 anos já fazia meus 'hello world!!!' e
com 17 anos estava fazendo um sistema de controle de estoque em
VB (hehehe, quem não faria), e de lá pra cá, trabalhar com
datas sempre me deixava, deixa e porque não, deixará com uma
pulga atrás da orelha.
E logo porque trabalhar com datas me deixa tão confuso? Ora usa-se um campo datetime ou timestamp e pronto certo? Certo, até precisarmos saber a distância (em dias, horas) entre duas datas, adicionar/subtrair um (ou mais) dia(s) em uma data, e tem coisa pior... e é por isso que servem aquelas funções mágicas para trabalhar com datas, em VB/ASP tínhamos funções maravilhosas; mas o resultado dependia de como o seu servidor estava configurado. Se a data estivesse no formato americano era um jeito, se estivesse em formato brasileiro, era outro, e se o servidor IIS estivesse diferente do SQL Server, aí segura neném... E o mais bacana de tudo; sempre tem uma conversão pra lá outra pra cá.
Então conheci (há uns 3 anos e meio) o fabuloso mundo do PHP e o MySQL, pelo melhor custo-benefício em hospedagem de pequenos sites (isso eu pensava na época, hoje em dia tenho total segurança nessa dupla).
Tive a necessidade óbvia de trabalhar com datas e para minha surpresa, os argumentos das funções date(), gmdate(), entre outras que formatam datas, tem como argumento opcional um tal de "unix timestamp".
Era só o que faltava, se vocês vissem a lista de funções que criei para automatizar as minhas datas... mas beleza, isso vai se normalizando quando começamos a pensar melhor e conversar com a galera que é um pouco mais experiente em PHP, olhar os exemplos de script.
Porém a maior mudança que tive na forma de armazenar datas em banco foi quando comecei a fuçar alguns projetos open-source, mais particularmente o phpBB.
Na próxima página explicarei essa mudança...
E logo porque trabalhar com datas me deixa tão confuso? Ora usa-se um campo datetime ou timestamp e pronto certo? Certo, até precisarmos saber a distância (em dias, horas) entre duas datas, adicionar/subtrair um (ou mais) dia(s) em uma data, e tem coisa pior... e é por isso que servem aquelas funções mágicas para trabalhar com datas, em VB/ASP tínhamos funções maravilhosas; mas o resultado dependia de como o seu servidor estava configurado. Se a data estivesse no formato americano era um jeito, se estivesse em formato brasileiro, era outro, e se o servidor IIS estivesse diferente do SQL Server, aí segura neném... E o mais bacana de tudo; sempre tem uma conversão pra lá outra pra cá.
Então conheci (há uns 3 anos e meio) o fabuloso mundo do PHP e o MySQL, pelo melhor custo-benefício em hospedagem de pequenos sites (isso eu pensava na época, hoje em dia tenho total segurança nessa dupla).
Tive a necessidade óbvia de trabalhar com datas e para minha surpresa, os argumentos das funções date(), gmdate(), entre outras que formatam datas, tem como argumento opcional um tal de "unix timestamp".
Era só o que faltava, se vocês vissem a lista de funções que criei para automatizar as minhas datas... mas beleza, isso vai se normalizando quando começamos a pensar melhor e conversar com a galera que é um pouco mais experiente em PHP, olhar os exemplos de script.
Porém a maior mudança que tive na forma de armazenar datas em banco foi quando comecei a fuçar alguns projetos open-source, mais particularmente o phpBB.
Na próxima página explicarei essa mudança...
Todos os meus arquivos possuem um include para um arquivo global de configuração do sistema, o config.inc. Nele possuo uma variável que armazena o formato do campo DATETIME do banco de dados usado pelo sistema. Por exemplo, pra MySQL defino a variável assim:
$formato_data = 'Y-m-d';
E pra SQL Server seria:
$formato_data = 'm-d-Y';
Se a regionalização mudar, basta mudar uma variável que a lógica das queries estarão automaticamente atualizadas e funcionando.
Quando vou montat um insert, faço da seguinte forma:
$data = date($formato_data);
$insert = "INSERT INTO tabela (data) VALUES ($data)";
Dessa forma não perdemos os recursos que o banco de dados oferece para cálculo de datas e nem precisamos fazer malabarismos nas queries quando mudamos de banco de dados. :P
Bom, taí outra alternativa.
[]'s