Hola Daniel.
Vi que mandaste dos correos con dos argumentos diferentes: uno sobre el
valor del álgrebra de fechas (funciones de fecha) y el otro sobre la
validación de las fechas.
Sobre el valor de las funciones de fecha, no las negué en mi primer
planteo. Y por supuesto que las utilizo.
Pero fijate que los parámetros que les mandás cuando los ponés como
constantes, son strings. Por eso justificaba mi pregunta.
De hecho, si tenés una tabla con dos campos c1 char(8) con fechas en
formato iso, y c2 datetime, las funciones de fecha funcionan exactamente
igual. (siempre y cuando no nos importe hh:mm:ss claro está)
En una prueba con un millos de filas, hay una ventaja de 1 segundo a
favor del formato datetime (en sql 2000).
( haciendo select datediff( dd, c1, getdate() ) from dbo.tablaPrueba ),
O sea que aunque parece ser más eficiente el uso de datetime, la
diferencia es bastante chica.
Sobre la validación, me parece un argumento más válido, para justificar
el uso de Datetime contra char(8), aunque alguna validación es
inevitable de cualquier modo, y sería posible, (por citar un ejemplo)
con un constraint que valide ISDATE(CAMPO).
Claro que al poner el tipo de dato datetime es un seguridad más estricta
de que en la base no van a entrar cosas que no sean fechas válidas.
En resumen, ganó datetime. (pero no me pidan que halle el número de
dias transcurridos desde el descubrimiento de América hasta la fecha de
hoy ;-) ) Al menos nó usando datediff
Muchas gracias por todas las respuestas
Saludos
D.Aisenberg
-----Mensaje original-----
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Daniel Calvin
Enviado el: Domingo, 01 de Abril de 2007 12:02 p.m.
Para: Daniel Aisenberg
Asunto: [dbms] tipo de datos para fechas
La pregunta del millon
Que pasaría con la eficiencia cuando alguien escriba de prepo en un
campo de la base de datos 20070229?????
Como evitas estos errores?
Quien y donde chequea tipos?
El costo del control de fecha válida?, quien lo haría?, con que costo?
Modestamente, me prece que es inventar la rueda y comprar muchos
problemas .....
Daniel Calvin
El día 1/04/07, Daniel Aisenberg <[EMAIL PROTECTED]> escribió:
Ok. Gracias. Cabe unas preguntas.
Veo que en las consultas, independientemente del formato, las fechas se
especifican como strings, por ejemplo:
select count(*) from orders where orderdate >='01-08-1997'
Caso contrario, tendremos que usar alguna funcion como Cast o Convert (o
alguna función que devuelva una fecha), con lo cual hay que ejecutar un
conversión, claro que se podría hacer antes de la consulta, por ejemplo:
Declare @FechaConsulta datetime
Set @FechaConsulta = cast('19970801' as datetime )
select count(*) from orders where orderdate >[EMAIL PROTECTED]
Se obtendrá el mismo resultado en performance?
Si voy a almacenar digamos unos millones de fechas en las que no me
interesan las hh:mm:ss , no sería más eficiente usar char(8) y guardar
directamente un string en formato ansi ?, con la precisión hasta el dia?
Igual el costo de almacenamiento sería 8 bytes.
Gracias
-----Mensaje original-----
De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Trafelati
Víctor Hugo
Enviado el: Sábado, 31 de Marzo de 2007 05:06 p.m.
Para: Daniel Aisenberg
Asunto: [dbms] tipo de datos para fechas
Pegale una mirada a este artículo de Maximiliano Acotto del MUG
"cómo manejar las fechas en sql server"
http://www.mug.org.ar/SQL/ArticSQL/240.aspx
----- Original Message -----
From: Diego A. Montero <mailto:[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Friday, March 30, 2007 10:21 PM
Subject: [dbms] tipo de datos para fechas
Yo guardo en formato numerico, yyyymmdd, y el soft se encarga de
"acomodarlo" para guardarlo en la base.
Puede que sea engorroso en algún momento, pero armando unas buenas
funciones en el soft todo se soluciona
Y me despreocupo si estoy en Access, SqlServer, Oracle, Informix, DB2.
No es "LA SOLUCION" pero para softwares multiplataformas sirve
_____
From: [email protected] [mailto: [email protected] <mailto:[email protected]>
] On Behalf Of Tixe
Sent: Friday, 30 de March de 2007 21:48
To: Diego A. Montero
Subject: [dbms] tipo de datos para fechas
estimo que se debe referir a que si se guarda en el formato "americano"
se aseguras que si no hay una consulta parametrizada, el resultado
siempre sea el buscado.
Tixe
_____
From: [email protected] [mailto: [email protected] <mailto:[email protected]>
] On Behalf Of Diego Jancic
Sent: Friday, March 30, 2007 9:30 PM
To: [EMAIL PROTECTED]
Subject: [dbms] tipo de datos para fechas
Hola Estaban,
A que te referis con grabar siempre como yyyy/mm/dd ?? Te pregunto
porque si usas consultas parametridas funciona siempre, pero dudo que te
refieras a eso, no?
_____
From: [email protected] [mailto: [email protected] <mailto:[email protected]>
] On Behalf Of Esteban Grinberg
Sent: Viernes, 30 de Marzo de 2007 18:23
To: Diego Jancic
Subject: [dbms] tipo de datos para fechas
Yo recomiendo usar datetime. Jamas vi una ventaja en usar otro tipo de
campo, como numerico o varchar. Si vi muchas desventajas (puede que tal
vez un filtro por datetime sea mas lenta, pero es solo un tal vez, no se
a ciencia cierta).
Lo unico importante es que para grabar, siempre grabes como YYYY/MM/DD,
asi garantizas que te va a andar bien en cualquier base de datos y en
cualquier configuración regional..
_____
De: [email protected] [mailto: [email protected] <mailto:[email protected]> ]
En nombre de Diego Jancic
Enviado el: viernes, 30 de marzo de 2007 21:12
Para: Esteban Grinberg
Asunto: [dbms] tipo de datos para fechas
Hola,
No se cual sera la respuesta basandose en la performance, pero creo que
si guardas una fecha en un campo del tipo datetime tenes la ventaja de
las funciones de sql sin tener que hacer cast todo el tiempo
Saludos!
_____
From: [email protected] [mailto: [email protected] <mailto:[email protected]>
] On Behalf Of [EMAIL PROTECTED]
Sent: Viernes, 30 de Marzo de 2007 20:18
To: Diego Jancic
Subject: [dbms] tipo de datos para fechas
Hola: quería preguntarles si hay alguna recomendación respecto del
almacenamiento de valores de fechas, en cuanto a tipo de dato del campo
de la tabla.
Conviene por ejemplo, guardarlas como campos char, en y la fecha en
formato ISO? o algún otro? o mejor directamente usar datetime? Qué
tendría que tener en cuenta?
Gracias.
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.23/740 - Release Date:
30/03/2007 01:15 p.m.
--
Daniel A. Calvin
Cooperator Team Member
http://www.cooperator.com.ar
Microsoft Certified Professional
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.24/741 - Release Date:
31/03/2007 08:54 p.m.
