¿Cuándo debe una tabla de base de datos usar marcas de tiempo?

Primero una nota, pensé que tal vez esta pregunta pertenecía al intercambio de bases de datos, pero creo que está más relacionada con una solución de programación en su conjunto que con las bases de datos. Se moverá al intercambio de bases de datos si la gente cree que es la mejor.

Me preguntaba cuándo una tabla de base de datos debería tener una marca de tiempo actualizada y creada.

La primera respuesta obvia es que si alguna lógica de negocios necesita saber cuándo se actualizó algo (como una fecha de finalización de la transacción, etc.), entonces debe entrar.

Pero, ¿qué pasa con los casos de lógica no comercial? Por ejemplo, puedo pensar en escenarios en los que sería realmente útil saber la fecha y hora en que las filas cambiaron para ayudar con la búsqueda de fallas, por ejemplo, fallan algunas lógicas de negocios y al observar las filas de la base de datos relacionadas es posible identificar que una fila se está actualizando antes otra fila que está causando el error.

Con este caso de uso, tendría sentido dar una actualización a cada tabla y crear una marca de tiempo (a excepción de quizás las tablas de enumeración más triviales que ninguna parte de la aplicación actualizaría).

Darle a cada tabla una marca de tiempo es seguramente una excelente manera de atascar rápidamente una base de datos (aunque podría estar equivocado).

Entonces, ¿cuándo debería una tabla de base de datos usar crear y actualizar marcas de tiempo?

Para una mejor y más completa gestión de bases de datos y la práctica más sabia es hacerlo.

Primero, es más probable que, como desarrollador, desee realizar un seguimiento de las transacciones y / o actividades de la base de datos para el desarrollo y facilidad para rastrear errores y errores en su código cada vez que involucra su base de datos.

Además, siempre que necesite realizar un seguimiento de las actividades realizadas en su base de datos con fines estadísticos .

Otra, es que a menudo sucede que quizás por el momento no necesite hacer un seguimiento de las actividades de su base de datos, pero es más probable que lo haga en el futuro. Necesitará su tiempo hoy, pero le compra más en el futuro .

Como alguien que ha sido tanto cazador furtivo (desarrollador) como gamekeeper (DBA), me sorprende que muchos todavía no vean el valor en esto y lo consideren inflado.

Simplemente pon:

Para cualquier tabla donde se agreguen registros (pero nunca se actualicen), por ejemplo, inicios de sesión, etc. Consideraría agregar una columna DATE_CREATED.

Para cualquier tabla donde se agreguen y actualicen registros, consideraría agregar una columna DATE_CREATED y una columna DATE_UPDATED.

He trabajado en muchos lugares donde DATE_CREATED y DATE_UPDATED se incluyen en cada tabla de forma predeterminada como parte del diseño.

Para bases de datos más grandes con millones / miles de millones de filas donde la actualización de la base de datos se ejecutó en el transcurso de unos días, también agregamos una columna FUENTE para algunas tablas que rastrearon qué bote de datos causó la actualización, por ejemplo, alimentación de terceros, actualización del usuario, modificación de DBA, limpieza de datos, etc.

Por la forma en que está formulada la pregunta, estás pidiendo una lista de cosas. Me arriesgaré a no responder directamente a su pregunta, sino a responder cuándo debe usar una solución alternativa.

Puedo pensar en escenarios en los que sería realmente útil saber la fecha y hora en que las filas cambiaron para ayudar a encontrar fallas

¿Sería más útil tener un registro de todas las actualizaciones para un registro dado? Solo conocer la última actualización, puede no ser suficiente información. Este registro podría colocarse en una tabla separada. Sería más conveniente realizar un seguimiento de los cambios de varias tablas en los mismos archivos de registro (no tiene que ser una tabla). Esto evita alguna consulta de unión masiva de todas las tablas change_dates para obtener agregados. Esto también beneficiaría la solución de problemas al ayudarlo a ver una grabación de más eventos en su sistema.

Además: también debe tener en cuenta a los usuarios. Es posible que no lo conviertan en un caso de negocios, pero cuando tiene usuarios sin experiencia o aquellos en una cultura corporativa donde nunca cometen un error de usuario y siempre quieren echarle la culpa a la computadora, cualquier tipo de registro ayudará a incluir las fechas de actualización en las tablas. En este caso, es posible que también desee tener un campo Update_UserID.

Una tabla de base de datos debe incluir plantillas de creación y modificación cuando se cumple alguna de las siguientes condiciones:

1. La tabla representa un registro primario de alguna actividad proporcionada por el usuario. Si el usuario hace X, y tiene ambos, a Table_Xy Table_Ya, hijos secundarios de uno a muchos Table_X, Table_Yno es un registro primario y, por lo tanto, no necesita los campos adicionales.
2. Cuando tiene una necesidad permanente, temporal o recurrente de seguimiento del sistema . Si necesita verificar que Table_Ysolo se actualiza cuando Table_Xse actualiza, los campos de seguimiento adicionales pueden ayudarlo.

Tenga en cuenta que ninguno de estos es exclusivo; puede continuar y agregarlos en todas partes de forma predeterminada, y omitir solo cuando sea necesario para el ajuste del rendimiento.

Opinión personal:

No veo el valor en una modifiedcolumna.

created, absolutamente, debe agregarse a cada tabla de base de datos a menos que haya una justificación excepcional para no hacerlo. Hay mucho valor en tenerlo allí.

Sin embargo, updatedparece un desperdicio. ¿Por qué no simplemente hacer todo el trabajo, hacer dos tablas de base de datos, una que especifique una ID de documento y otra la versión del documento? En un caso muy simplista

create table document (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

create table version (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    document_id INT NOT NULL REFERENCES document(id),
    content TEXT NOT NULL,
    created TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

Luego seleccione la última versionde las documentque desee. De esta manera, no solo guarda todas las fechas de modificación, no solo la última, sino que también conserva todas las versiones de ese documento. El único argumento en su contra es realmente el espacio en el disco duro, pero seguramente cuando llegue al punto en que esté preocupado por el espacio en el disco duro que está utilizando, en la mayoría de los casos le molestaría aún más la versión de los datos.