Fecha de almacenamiento como entero (numérico), ¿cuáles son las ventajas?

Pregunta 1

Estoy trabajando con un sistema donde la fecha se almacena como un número entero (numérico real (8,0)) y he notado que otros sistemas también almacenan la fecha como int como cisco en este hilo . Ejemplo

20120101  -- 01 Jan 2012

¿Hay alguna ventaja de mantener el sistema de fecha numérico y no usar SQL Datetime?

Pregunta 2

Ahora estoy tratando de recorrer la fecha numérica para encontrar clientes entre dos fechas. Si starty enddateabarca dos meses, obtengo miles de registros en lugar de solo 60. Ejemplo:

create table #temp1(day int,capacity int) /* just a temp table */

declare @start int 
declare @end int

set @start=20111201
set @end = 20120131

while (@start <= @end) 
Begin
    insert into #temp1  /* I am storing things in #temp table so data looks pretty */
    exec usp_GetDailyCap @date1= @start

    set @start = @start + 1;    
end

select * from #temp1

Esto extrae 8931 registros en lugar de 60. ¿Hay una mejor manera de mejorar la lógica anterior para que solo extraiga fechas válidas? Intenté IsDate y las subconsultas, pero eso no funcionó de manera eficiente.

sql-server sql-server-2008 date-format

— Jackofall
fuente

Si está ejecutando SQL Server 2008 o superior, en realidad solo puede usar el tipo de datos Fecha. Es un poco más pequeño y no te obliga a incluir el tiempo, pero casi todas las funciones de fecha y hora de SQL todavía funcionan para él.

— DForck42

Solo veo desventajas en este enfoque, ninguna ventaja

— a_horse_with_no_name

Respuestas:

Para responder a su primera pregunta, recomendaría usar el DATETIMEtipo de datos dentro de SQL Server. No necesariamente por razones de rendimiento, sino para aprovechar la funcionalidad específica de RDBMS. Por ejemplo, tendría que volver a inventar un montón de lógica sólo para hacer operaciones matemáticas básicas fecha (cree DATEDIFF(), DATEADD(), DATEPART()y muchas otras funciones. Es evidente que están adaptados al DATETIMEtipo de datos y son fáciles de trabajar con).

En cuanto a su segunda pregunta, se encuentra con el problema exacto al que se dirige la primera pregunta (y mi respuesta) . Estás viendo 20111201 y 20120131 como fechas, y tu cerebro te dice que debería ser una diferencia de 60 días. Bueno, estás recorriendo en base al delta ... que es:

20120131 - 20111201 = 8930 (con el bucle inclusivo será 8931)

En otras palabras, su WHILEciclo se está ejecutando 8931 veces. Esto está sucediendo porque esos son valores enteros y su ciclo no saltará de 20111231 directamente a 20120101.

Sus enteros no van a tener en cuenta el límite de años y meses (es decir, su problema de la Pregunta 2 ).

— Thomas Stringer
fuente

Bueno, esa es exactamente mi pregunta. Para fechas numéricas, los bucles pueden llegar a miles, no solo 30 días o 29 días. Pero hay que tener en cuenta que estoy trabajando con un sistema profesional . E incluso Cisco lo usa como parece.

— Jackofall

Además del rendimiento y la funcionalidad, también hay integridad. Con números enteros como fechas, el PP permitiría 20121301e 20120230incluso 20129999como una fecha.

— ypercubeᵀᴹ

@Jackofall Cisco no tiene la plataforma de un RDBMS detrás de él. Escribieron su propia lógica. ¿Por qué no usarían enteros? Desde cero, esa es probablemente la forma más fácil de software de bajo nivel. Pero estamos hablando de manzanas y naranjas aquí.

— Thomas Stringer

@Jackofall: hay una gran diferencia entre almacenar fechas como enteros (y tener espacios) y almacenar fechas / marcas de tiempo como enteros, o incluso fechas como enteros, como lo hace VB / Excel.

— ypercubeᵀᴹ

Hay muchas (si no la mayoría) bases de datos diseñadas profesionalmente que usan malas técnicas. He trabajado con muchos productos COTS y no he visto ninguno que esté bien diseñado desde la perspectiva de una base de datos.

— HLGEM

Ralph Kimball recomienda almacenar fechas como números enteros. Ha escrito mucho, tanto artículos en línea como libros.
Puede usar una tabla de calendario y emitir números consecutivos a sus fechas, de la siguiente manera:

Número de fecha

20120229 1234

20120301 1235

Se debe generar la tabla de calendario, pero es una tarea muy fácil.

— Alaska
fuente

Me gustaría ver el caso en el que se filtra una consulta uniéndose a una tabla de fechas con las fechas almacenadas como numéricas y filtrando esas fechas numéricas se superaría usando "where [date] entre @startdate y @enddate"

— DForck42

@ DForck42 no es necesario el caso que sugiere: "where [dateAsInt] entre 20120229 y 20120329" devolvería exactamente las mismas filas que "where [date] entre '20120229' y '20120329'"

— AK

¿Y cuál fue su razonamiento?

— HLGEM

Tipos de datos potenciales y sus tamaños / limitaciones:

Decimal (8,0): 5 bytes
Fecha: 3 bytes, 0001-01-01 a 9999-12-31
Int: 4 bytes

Pros para el tipo de datos numéricos:

Se ven bonitas?

Contras para el tipo de datos numéricos:

Requiere código personalizado para manejar operaciones de fecha
Requiere un código personalizado para administrar las fechas correctas (es decir, no permitir 20120230 [30 de febrero de 2012])
Mayor huella de datos en comparación con el tipo de datos Fecha.

Honestamente, es mejor usar el tipo de datos de fecha en mi humilde opinión.

— DForck42
fuente