Estes dias estou cuidando de uma tarefa para lá de delicada. Tenho que importar dados de um recadastramento com uns 80 mil registros que vão atualizar todo um sistema que vai impactar na receita daqui. Grana no meio, ordem de lá de cima, muita pressão.

Bem, importei os dados em TXT para uma tabela no banco e criei um PL/SQL para integrar os dados com o sistema. São ao todo umas 50 operações de INSERT, UPDATE, DELETE em meio a uns 20 loops no meio, umas duas dúzias de tabelas sendo alteradas e algumas subconsultas cabeludas no meio. Montei uma tabela para logar os erros e outra para logar o andamento de cada registro. Em pouco tempo - leia-se alguns dias trabalhando alucinadamente… estou com o processo todo rodando na minha base de teste. Após os primeiro 1000 registros rodarem, fiz minha estimativa de tempo par o término da operação completa… algo entre 7 e 8 dias.

Opa… pintou problema! Se isso não terminar logo não entra dimdim no caixa… bem, resolvo liberar lotes de atualização para o pessoal ir testando os dados atualizados. Bem, lá fui eu dar a má notícia para a equipe de testes, avisando que já havia um lote com mil registros que podiam ser testados.

- Ok, vamos começar a testar amanhã de manhã. Você lembrou de colocar 5 zeros á esquerda da chave primária principal?

- Não amiguinha. Quando o dado é numérico os zeros a esquerda não fazem diferença no banco de dados. Eles só aparecem na mascara de exibição da aplicação…

- Ah bom, é porque todo mundo sempre coloca os 5 zeros concatenados a esquerda. Então tudo bem!

- Fica fria. Isto só seria importante se os dados fossem do tipo texto. Como se trata de um número inteiro, não tem problema.

- Hum… deixa eu ver uma coisa aqui…

Surpresa. O sistema utilizava dados numéricos num campo do tipo CHAR(15)!!! Bem na chave primária da tabela principal. Quem é que em sã consciência armazena uma chave primária inteira como texto? Heim, heim, heim? A besta aqui não olhou este “detalhe” nas tabelas do sistema. Mais uma vez a pressa me pregou uma peça fantástica. Já lá pelas 20 horas volto para a prancheta e começo a arrumar toda a bagunça.

- O que vamos fazer amanhã a noite?
- Tentar dominar o mundo…mas podemos socar alguns devenvolvedores idiotas primeiro!!!

O sujeito fala comigo ao telefone:
- Cria uma campo “timestamp’
Eu respondo:
- Claro, qual o nome do campo?
- Eu disse ‘timestamp’!
- Ok vou dar uma olhada depois ligo de volta.

Fiquei com medo de estar parecendo ignorante. Como não conheço direito quem está do outro lado da linha, achei que eu podia estar comendo bola. E lá fui eu fuçar nas tabelas do Oracle 9i para ver se eu entendia o que a minha santa ignorância não foi capaz de compreender. E não demorou muito para eu entender o que o nosso amigo estava querendo dizer. “Timestamp” era o nome do campo e o tipo de dados era lgicamente o tipo DATE!!!

Em algumas leituras recentes sobre o PL/SQL do Oracle descobri o motivo de tal estranheza. O Oracle só incluiu o tipo de dados TIMESTAMP a partir da verso 9i, que é justamente a verso com a qual trabalho. Como eu j trabalho com GNU/Linux a algum tempo procurei logo de cara o tipo de dados TIMESTAMP que sempre utilizei no PostgreSQL. Os sistemas Unix sempre armazenaram data e hora no formato TIMESTAMP, o padrão SQL já adota o TIMESTAMP a partir do SQL92, mas a ORACLE… só agora resolveu adotar.

Aí a besteira do meu colega na linha telefnica… ao invés de utilizar um campo com o nome “data_criacao” ou algo significativo, utilizou uma palavra reservada para nome da coluna. Bem, o livro que estou lendo da ORACLE PRESS realmente recomenda não utilizar palavras reservadas como nomes de colunas, mas antes do Oracle 9i, TIMESTAMP não era uma palavra reservada. O código fica bastante confuso, mesmo se estiver bem endentado. A chance de fazer uma confusão é grande…

O mais estranho é que quando dou um:

> SELECT data_no_formato_date FROM alguma_tabela

no Oracle ele no retorna hora, minuto e segundo. Você precisa esplicitar isso como em:
>SELECT to_char(data_no_formato_date, ‘DD-MM-YYYY HH24:MI:SS’) FROM alguma_tabela

Então eu descobri o milagre… você tem de setar uma variável de ambiente que controla o formato defaut de visualização, ou usar a função to_char para definir explicitamente o formato de exibição de datas como acima.

O legal da máscara que está aqui é que se eu dou um:

> SELECT data FROM alguma_tabela WHERE data = ‘01-JAN-01′

O Oracle acha que o ano 1901, 1801 e 2001 são o mesmo ano. Não é uma maravilha?

Quer um conselho, não use DATE no Oracle 9i use o tipo de dados TIMESTAMP e de preferência ponha um nome melhor para o nome de suas colunas.