SQL - Diseño de tabla - Columnas DateCreated y DateUpdated

Question

Para mi aplicación hay varias clases de entidad, Usuario, Cliente, Publicación, etc.

Estoy a punto de diseñar la base de datos y quiero almacenar la fecha en que se crearon y actualizaron las entidades. Aqui es donde se pone complicado. Una de las opciones es agregar las columnas created_timestamp y update_timestamp para cada una de las tablas de entidades, ¿pero eso no es tan redundante?

Otra posibilidad podría ser crear una tabla de registro que almacene esta información, y podría contener un seguimiento de las actualizaciones de cualquier entidad .

¿Algún pensamiento? Me estoy apoyando en la implementación de este último.

Answer 1

El enfoque de una sola tabla de registro para todas las tablas tiene dos problemas principales en los que puedo pensar:

1. El diseño de la tabla de registro (probablemente) restringirá el diseño de todas las otras tablas. Lo más probable es que la tabla de registro tenga una columna llamada TableName y luego otra columna llamada PKValue (que almacenaría el valor de clave principal para el registro que está registrando). Si algunas de sus tablas tienen claves primarias compuestas (es decir, más de una columna), entonces el diseño de su tabla de registro debería tener esto en cuenta (probablemente al tener columnas como PKValue1, PKValue2, etc.).
2. Si se trata de una aplicación web de algún tipo, entonces la identidad del usuario que estaría disponible desde un activador sería la cuenta de la aplicación, en lugar del ID del usuario de la aplicación web (que es lo más probable que sea lo que realmente desea almacenar). en su campo CreatedBy). Esto solo le ayudaría a distinguir entre los registros creados por el código de su aplicación web y los registros creados de otra manera.

Las columnas CreatedDate y ModifiedDate no son redundantes solo porque están definidas en cada tabla. Me apegaría a ese enfoque y pondría los activadores de inserción y actualización en cada tabla para completar esas columnas. Si también tuviera que registrar al usuario final que realizó el cambio, omitiría los desencadenantes y rellenaría la marca de tiempo y los campos de usuario de mi código de aplicación.

Answer 2

Hago lo último, con un " registro " o " eventos " mesa. En mi experiencia, el " actualizado " la marca de tiempo se vuelve frustrante bastante rápido, porque la mayoría de las veces te encuentras en una situación en la que quieres no solo la última actualización.

Answer 3

¿Con qué frecuencia necesitará incluir las marcas de tiempo creadas / actualizadas en su capa de presentación? Si la respuesta es algo más que "una vez en un gran momento", creo que sería mejor tener esas columnas en cada tabla.

Answer 4

En un proyecto en el que trabajé hace un par de años, implementamos activadores que actualizaron lo que llamamos una tabla de auditoría (almacenaba información básica sobre los cambios realizados, una tabla de auditoría por tabla). Esto incluyó la fecha de modificación (y la última modificación).

Solo se aplicaron a las tablas clave (no a las combinaciones ni a las tablas de datos de referencia).

Esto eliminó gran parte de la frustración normal de tener que dar cuenta de LastCreated & amp; Campos LastModified, pero introdujo la molestia de mantener los activadores actualizados.

Al final, el diseño de la tabla de activación / auditoría funcionó bien y todo lo que tuvimos que recordar fue eliminar y volver a aplicar los activadores antes de ETL (!).

Answer 5

Es para un CMS basado en web en el que trabajo. La creación y las últimas fechas actualizadas se mostrarán en la mayoría de las páginas y habrá listas para las últimas páginas creadas (y actualizadas). La interfaz de administración también utilizará esta información.