¿Debe una tabla de registro obtener un campo de identificación o clave primaria?

12

Tengo una tabla de registro que captura la marca de fecha y hora de cuando ciertos archivos se exportaron a otro sistema.

La tabla exportedLog actualmente tiene tres campos:

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

Al revisar esto, descubrí que el idcampo no sirve para nada, ya que no hay combinaciones en esta tabla. Lo único que funciona en esta tabla es la inserción del trabajo por lotes que procesa los mensajes y se inserta en esta tabla de registro.

¿Debo eliminar el idcampo?

Debería tener una clave principal en cualquiera messageIdo exportedDateTimeo ambos?

kacalapy
fuente
2
¿Para qué DBMS es esto?
ypercubeᵀᴹ

Respuestas:

10

¿Debo eliminar el campo id?

Yo recomendaría guardarlo.

Es posible que no necesite el campo ahora , pero en el futuro, realmente puede ayudarlo, ¿qué sucede si necesita almacenar detalles de los archivos para cada entrada de registro?

No sé qué tan grande será esta tabla y qué tan rápido, pero agregar una columna a una tabla grande suele ser una operación costosa. Si la tabla es relativamente pequeña, no es un gran problema mantenerla en términos de espacio de almacenamiento. OMI, mantenga la columna y ahorre un posible dolor de cabeza más tarde.

¿Debo tener una clave principal en messageId o exportedDateTime o en ambos?

No parece que messageIdsolo sea único en esta tabla (aunque podría estar equivocado), y crear unicidad en una columna de fecha / hora solo puede potencialmente crear duplicados (y, por lo tanto, errores). La única opción que queda es una clave de 2 columnas, que no es particularmente atractiva dado el escenario que expuse anteriormente.


Esencialmente, mi punto de esta respuesta es que mantener la columna no es un gran problema (supongo), pero necesitarlo más tarde puede ser un gran problema y / o requerir un trabajo adicional para volver a colocarlo.

Jon Seigel
fuente
6
  • Si no tiene combinaciones en esta tabla, no hay actualizaciones ni eliminaciones, entonces no necesita claves en absoluto.

  • Si este no es el caso y messageIdes único, puede convertirlo en una clave principal.

  • Si no es único, pero lo (messageId, exportedDateTime)es, entonces conviértalo en una clave primaria compuesta.

  • Si incluso la (messageId, exportedDateTime)combinación puede proporcionar duplicados y actualizaciones y eliminaciones (puede ser necesario eliminar filas insertadas accidentalmente), será mejor que deje el idcampo como está.

dezso
fuente
0

Una Clave primaria no dañará ... si considera el propósito del registro / auditoría, probablemente se usará (consultará) en el futuro para resolver un problema o restaurar datos, etc. y probablemente se unirá a otros tablas existentes de no registro / auditoría para realizar ese tipo de trabajo.

Mark E
fuente