database - tipos - Diseño de la base de datos: ¿debe usarse una fecha como parte de una clave principal?

tipos de claves en access (10)

¿Cuáles son los pros / contras para incluir un campo de fecha como parte de una clave principal?

Como siempre ... Depende.

¿Cuál es su objetivo de incluir una columna de fecha / hora en un PK? ¿Es para proporcionar información adicional sobre un registro sin tener que seleccionar realmente la fila?

El principal problema que puedo prever aquí son los más obvios, es decir, ¿utiliza una fecha UTC o una fecha local? ¿Se malinterpretará la fecha (alguien pensará que significa hora local cuando significa UTC)? Como algunos de los otros han sugerido, ¿podría usarse mejor en una clave sustituta / compuesta? Puede ser mejor para su rendimiento usarlo en una clave o índice que no sea la clave principal.

[Nota al margen] Esto me recuerda la teoría detrás de un (1) COMB (GUID combinado) aunque la idea aquí era crear un ID único para un PK que SQL Server mejor indexara / requiriera menos reconstrucción del índice, en lugar de agregar cualquier valor significativo de fecha / hora en una fila.

(1) [ http://www.informit.com/articles/article.aspx?p=25862&seqNum=7]

Estoy de acuerdo con que sea parte de la clave, pero agregaría que también debe tener un número de secuencia de auto incremento como parte de la PK, y exigir que cualquier fecha se escriba en la base de datos como UTC, con los sistemas posteriores que convirtiendo a la hora local.

Un sistema en el que trabajé decidió que sería una gran idea tener un activador de Oracle escribiendo en una base de datos cada vez que tocaban otra tabla, y hacer que sysdate fuera parte de la clave principal sin número de secuencia. El único problema es que si ejecuta una consulta de actualización que golpea la fila más de una vez por segundo, rompe la clave primaria en la tabla que está registrando el cambio.

Fecha como único o primer componente de una clave principal que causa problemas de rendimiento en tablas con inserción alta. (La tabla deberá reequilibrarse con frecuencia).

A menudo causa un problema si se insertan más de uno por Fecha.

En la mayoría de las situaciones, considero que es un mal olor y desaconsejaría.

Hay algunas preguntas que le preguntaría sobre el uso de una fecha como parte de la clave principal.

¿La fecha incluye la porción de tiempo? Esto dificulta las cosas porque el tiempo incluye zonas horarias y ahorro de luz natural. Esto no altera el valor de fecha / hora, pero puede producir resultados inesperados en términos de clasificación o recuperación de valores basados en una consulta.

Soy un gran creyente en el uso de claves sustitutivas (es decir, uso de una columna de secuencia como clave principal) en lugar de claves naturales (como el uso de una fecha).

Las fechas son claves primarias perfectamente buenas, siempre que tengan sentido como parte de la clave natural. Usaría una fecha en tablas como:

holiday_dates (fecha de hol_date)
employee_salary (employee_id entero, sal_start_date date)

(¿Cuál sería el sentido de agregar el sustituto employee_salary_id anterior?)

Para algunas tablas, se puede usar una fecha, pero otra cosa tiene más sentido como clave principal, por ejemplo:

hotel_room_booking (reservation_reference)

Podríamos haber usado (room_no, booking_from_date) o (room_no, booking_to_date), pero una referencia es más útil para comunicarse con el cliente, etc. Podríamos convertir esto en restricciones ÚNICAS, pero de hecho necesitamos una verificación más compleja de "no superposición" para éstos.

No hay nada especialmente malo en esto, pero como otros carteles han notado que usted podría tener problemas con las zonas horarias y los lugareños. También puede terminar con muchas funciones DATE () que confinan su SQL.

Si se trata de algo así como el inventario al final del día como se mencionó anteriormente, tal vez podría considerar un campo de texto de ocho caracteres como "20081202" como la segunda parte de la clave principal. Esto evita los problemas de configuración regional de la zona horaria y es bastante fácil de convertir a una fecha real si es necesario.

Recuerde que la clave principal tiene dos funciones para identificar unívocamente un registro y para hacer cumplir la singularidad. Las claves primarias sustitutas no lo hacen.

Una pequeña estafa sería que no es tan elegante como otros identificadores

(por ejemplo, decir a un colega, por favor, ¿puede mirar el registro 475663 es un poco más fácil que decir, por favor, puede ver 2008-12-04 19:34:02)

También existe el riesgo de confusión sobre el formato de fecha diferente en diferentes lugares

(por ejemplo, 4 de marzo de 2008 - 4/3/2008 en Europa, 3/4/2008 en EE. UU.)

(Mi preferencia siempre es utilizar una columna de clave separada)

Usar la fecha como parte de la clave principal podría hacer que las uniones en la tabla sean significativamente más lentas. Preferiría una clave sustituta y luego un índice único en la fecha si fuera necesario.

si ya ha decidido usar una clave primaria "natural", entonces la pregunta es: ¿es la fecha una parte necesaria de la clave principal, o no? ¡los pros / contras son irrelevantes!

Considere una tabla de inventario de piezas: si desea almacenar el nivel de inventario al final de cada día, una clave primaria compuesta en part_id y date_of_day estaría bien. Puede optar por convertirla en una clave única y agregar una clave primaria sintética, especialmente si tiene una o más tablas que hacen referencia a ella con una restricción de clave externa, pero aparte de eso, no hay problema.

Por lo tanto, no hay nada necesariamente incorrecto en ello, pero como cualquier otro método, puede usarse incorrectamente como en el ejemplo de Patrick.

Editar: Aquí hay otro comentario para agregar.

Me recuerda algo que escribí hace un tiempo sobre el tema de si los valores de fecha en las bases de datos eran realmente naturales o sintéticos. La representación legible de una fecha como "AAAA-MM-DD" es ciertamente natural, pero internamente en Oracle esto se almacena como un número que solo representa esa fecha / hora particular para Oracle. Podemos elegir y cambiar la representación de ese valor interno en cualquier momento (a diferentes formatos legibles, o a un sistema de calendario diferente por completo) sin que el valor interno pierda su significado como esa fecha y hora en particular. Creo que, sobre esa base, un tipo de datos DATE se encuentra en algún lugar entre natural y sintético.