separar - La mejor forma de almacenar fechas antiguas en SQL Server

obtener mes y año de una fecha sql

Question

¿Cuál es la mejor / la forma más eficiente de almacenar fechas antiguas (anteriores a 1753) en SQL Server 2005? No me preocupa almacenar tiempos, solo fechas. El tipo de datos datetime de SQL Server solo puede contener fechas del 1 de enero de 1753. La documentación de MSDN indica que hay tipos de datos date y datetime2, pero SQL Server Management Studio no parece ser compatible (Error: tipo de datos no válido).

¿Qué tan ineficiente sería almacenar fechas como cadenas o entradas de la forma "AAAAMMDD"? Hago muchas consultas y clasifico en dos campos de fecha en mi tabla (StartDate y EndDate).

ACTUALIZAR:

A continuación se incluyen algunas sugerencias para almacenar el año, el mes y la fecha en campos separados. ¿Cuál es la ventaja de almacenar las piezas en diferentes campos en lugar de en un único campo entero?

Answer 1

AAAAMMDD = 8 bytes. Puede cortarlo a 4 bytes con SMALLINT y TINYINT usando 3 columnas.

Answer 2

Las cadenas probablemente serían menos eficientes que simplemente almacenar enteros para el año, mes y día. Eso es un poco más verborrea en sus consultas, pero es probable que funcionen más rápido, ya que puede indexarlos de manera que tengan sentido para los tipos de consultas que está haciendo.

Así por ejemplo:

CREATE TABLE myOldDates (
  year INT,
  month INT,
  day INT,
  -- otherstuff ...
)

Entonces las consultas serían todas como:

-- get records between 5/15/1752 and 3/19/1754
SELECT * FROM myOldDates
  WHERE 
    (year = 1752 AND ((month = 5 and day >= 15) or month > 5) OR year > 1752)
    AND (year = 1754 AND ((month = 3 and day <= 19) or month < 3) OR year < 1754)

Eso es feo, sin duda, pero es tan feo como para las consultas de rango, por lo que una vez que lo escriba la primera vez, puede encapsularlo en una función.

Answer 3

Nunca he hecho esto, pero tal vez podría almacenar la fecha como un número entero que representa el número de días desde la fecha mínima que más le convenga. Luego, puede crear una tabla de búsqueda que correlacione esos enteros con un año, mes y día, o puede escribir funciones definidas por el usuario para convertir de un número entero a una fecha o viceversa.

Eso debería ser bastante eficiente en términos de selección y clasificación.

Answer 4

Una idea: si tiene algún conocimiento de .NET, podría crear un tipo de CLR para almacenar la fecha, que esencialmente sería una fecha y hora. Si está haciendo muchos cálculos con la fecha en lugar de simples consultas, podría ser algo para investigar

Answer 5

Usar enter como lo sugiere CodeMonkey1 parece una buena idea, y hará que sea más fácil hacer "math de fecha" (por ejemplo, alguna fecha + XX días).

Escriba algunas UDF (también según lo recomendado por CodeMonkey1) para convertir int -> YYYYMMDD -> int y tendrá la flexibilidad que Ian Varley menciona en su respuesta.

Answer 6

El tipo de date es definitivamente lo que quieres usar. Su rango es "1 de enero de 1 AD hasta el 31 de diciembre de 9999 AD". También almacena información de fecha, sin la parte de hora.

¿Está usted, tal vez, utilizando SSMS 2005, en lugar de 2008, o conectado a una instancia de 2005? Ese tipo fue introducido en SQL Server 2008 . Si tiene la capacidad de utilizar una base de datos de 2008, creo que es indudablemente el camino a seguir.

Answer 7

Un problema con el almacenamiento de fechas en el formato AAAAMMDD es que puede terminar con fechas que no existen (p. Ej., 16000231 - el 31 de febrero no existe). Debería hacer un lado del cliente de validación, antes de ingresarlo en el archivo db.

Lo mismo ocurre con el couse verdadero para almacenar la fecha en enteros de año, mes y día, según lo propuesto por Ian Varley . Pero aparte de eso me gusta su respuesta y me gustaría haberlo pensado ;-)