Clave principal de SQL Server en el campo de fecha y hora

Question

Estoy creando una nueva tabla en SQL Server 2005 que necesita 2 campos: DateTime y MyValue (Int32). El campo DateTime será único, por lo que estableceré una restricción única en él.

¿Qué estructura de la mesa es mejor y por qué?

MyIndex (PK, int)
MiFecha (fecha y hora) (IX_UniqueKey)
MyValue (int)

o

MiFecha (PK, fecha y hora)
MyValue (int)

Mi sensación es que no quiero un PK artificial (MyIndex) en esta tabla porque es innecesario y porque las fechas serán únicas. Las usaré para acceder a cualquier registro. Sin embargo, puede ser que sea más eficiente tener un PK artificial ...

Answer 1

Cuando diga que las fechas serán únicas, ¿quiere decir que piensa que serán únicas, o su exclusividad está garantizada por la declaración del problema? En mi experiencia, algunas cosas resultan ser mucho menos únicas de lo que uno imagina (los números de la seguridad social de EE. UU. Son un ejemplo).

Si los valores de fecha no se garantizan como exclusivos, debe agregar la clave entera.

Si los valores de fecha son únicos, ¿cambian? Si cambian, ¿están referenciados por otras tablas? Si ambas respuestas son "sí", probablemente debas agregar la clave entera.

Si los valores de fecha son únicos y no cambian o no se mencionan, puede usarlos para la clave. Los DATETIMEs regulares tienen 8 bytes y los valores INTEGER estándar son 4 bytes, lo que podría tener un efecto menor en la indexación. Si los valores de fecha son solo fechas, o solo exactas al minuto o menos, y en el rango más restringido permitido por el tipo, puede usar SMALLDATETIME y obtener esos valores de índice hasta 4 bytes.

Answer 2

No, su intuición es correcta. Mientras nadie pueda deslizar dos (o supongo que más) eventos simultáneos en usted dada la resolución disponible de su proceso de recopilación de datos, usted es Hunky Dory.

Answer 3

Si tiene la garantía de que las fechas siempre serán únicas (piense en la resolución del componente de tiempo), entonces la creación de la clave primaria en la columna de fecha y hora es una buena opción.

Si solo va a insertar cada vez más fechas y horas, la creación del índice agrupado en la columna de clave principal también es una buena opción.

Answer 4

Si el valor DATETIME será poblada por la base de datos IE:

INSERT INTO your_table 
    (mydate, myvalue) 
VALUES 
    (GETDATE(), 1234) 

... entonces sí, por lo que la columna de la mydate la clave principal es la solución ideal. Si la fecha es proporcionado por la aplicación IE:

INSERT INTO your_table 
    (mydate, myvalue) 
VALUES 
    (@my_date_value, 1234) 

... @my_date_value suponiendo que no está siendo suministrado por la base de datos - no, no es lo ideal. No se puede garantizar que una fecha distinta de la base de datos sea precisa en función de la inserción.