Bom, gente… Só a nível de curiosidade. Eu até acho a pergunta meio absurda, mas como não tenho um conhecimento vasto sobre o assunto, aí vai:
Um cliente da empresa onde trabalho pediu um sistema e que nesse sistema, os campos Date fossem persistidos no banco como tipo Inteiro, dizendo ele que seria melhor em relação ao desempenho. E isso não é tudo: campos CNPJ e CPF também, ao invés de String, ele pediu que usasse Inteiro. Bom, eu acho isso meio absurdo, como eu disse, pois fica mais difícil de manipular, mas pergunto a vocês se isso tem cabimento… se ele pode ter um mínimo de razão nisso.
Desde já, agradeço a atenção.
Atenciosamente,
novato
ja li que a data 0 em inteiro é considerada a data 12/11/1899 , não sei se irá adiantar muito …
O quão gigante será a computação no banco?
Tipo, SP que podem levar horas para executar?
Caso contrário, não faz o menor sentido oq ele tá falando…
Primeiro que, até onde sei, a maioria dos bancos guarda datas como inteiros internamente, e somente os transforma em datas no formato ‘dd/MM/yyyy’ quando é utilizado alguma função específica de calendário. Ex: EXTRACT(), TRUNC(), YEAR()
Segundo, do que vale ele ganhar alguns nanosegundos, se a cada fez que ele retirar estas datas do banco, ele ter que transformar em objetos do tipo Date? E onde fica a parte de manutenibilidade do código? Um código onde as colunas datas não são datas será um inferno para qualquer programador subsequente.
[quote=novato22]Bom, gente… Só a nível de curiosidade. Eu até acho a pergunta meio absurda, mas como não tenho um conhecimento vasto sobre o assunto, aí vai:
Um cliente da empresa onde trabalho pediu um sistema e que nesse sistema, os campos Date fossem persistidos no banco como tipo Inteiro, dizendo ele que seria melhor em relação ao desempenho. E isso não é tudo: campos CNPJ e CPF também, ao invés de String, ele pediu que usasse Inteiro. Bom, eu acho isso meio absurdo, como eu disse, pois fica mais difícil de manipular, mas pergunto a vocês se isso tem cabimento… se ele pode ter um mínimo de razão nisso.
Desde já, agradeço a atenção.
[/quote]
Sistemas com qualidade são coerentes. A primeira regra de coerencia é :use os tipos certos.
mesmo que fosse verdade - que não é - que usar os tipos errados aumenta seja lá o que for, não seria licito usar isso. Seria, é, uma gambiarra.
Campos CPF , CNPJ ,e outro tipos de codigos assim como telefones não são numeros , ou seja, não se pode fazer contas com eles ou procurar minimos e máximos. O tipo certo no banco é char fixo com o numero de letras que o codigo suporta
Data devem ser guardadas no tipo Date do banco. Datas com horas devem ser guardadas no tipo DateTime (timestamp) do banco.
Porque senão vc vai ter surpresas quandos fizer queries…
Usar os tipos errados não é meio absurdo, é grotescamente absurdo. Essa ideia só poderia vir da cabeça de um ruminante.
Não deixe o cliente interferir nas decisões tecnicas. Se ele insistir faça-o assinar um termo de responsabilidade.
Senhores,
Obrigado pelas respostas. Certamente, farei o que o sergiotaborda sugeriu. 
Atenciosamente,
novato22
