¿Cómo hago cumplir una tabla de base de datos de escritura única y luego de solo lectura en SQL?

¿Es posible?

Mi caso de uso es una tabla contable, con el requisito de que una vez que se crea un registro, debe ser de solo lectura, es decir, nadie debe poder editarlo ni eliminarlo. Esto solo se aplica a la tabla contable y a las tablas que tienen una relación directa con ella: hay otras tablas en el mismo esquema que se actualizarán / eliminarán de la forma habitual.

Tengo entendido que, para fines de integridad de datos, este tipo de restricciones deberían aplicarse en la capa de la base de datos, pero no puedo encontrar una forma limpia y ampliamente aceptada de hacerlo; este es un caso de uso en el que sería mejor hacerlo en la capa de aplicación?

Lo ideal sería una forma de hacerlo en SQL simple, para ser agnóstico de lo que se utiliza la plataforma DB, ya que puede estar sujeto a cambios, pero me doy cuenta de que puede ser demasiado pedir, por lo que si tiene para ser dependiente de la plataforma, se prefiere algún sabor de MySQL.

¡Gracias!

Veo al menos dos formas de lograr esto. El primer enfoque es no otorgar DELETEy otorgar UPDATEprivilegios en estas tablas de escritura única, o, para el caso, ningún privilegio aparte INSERTy SELECT, por lo tanto, solo permitir a los usuarios insertar o seleccionar entre ellos.

Otra opción es definir BEFORE UPDATEy BEFORE DELETEdisparar en estas tablas y usar la SIGNALinstrucción para generar una excepción en el cuerpo del disparador, lo que evitaría actualizaciones y eliminaciones respectivamente.

Los permisos parecen ser la opción obvia, sin embargo, también puede usar el ARCHIVE Storage Engine . Este motor de tablas está diseñado para registrar grandes cantidades de datos que no cambiarán:

El motor ARCHIVO admite INSERTAR, REEMPLAZAR y SELECCIONAR, pero no ELIMINAR o ACTUALIZAR. Admite operaciones ORDER BY, columnas BLOB y básicamente todos menos tipos de datos espaciales (consulte la Sección 11.5.1, “Tipos de datos espaciales”). El motor ARCHIVE usa bloqueo de nivel de fila.

La diferencia con los permisos es que alguien con privilegios extendidos aún podría cambiar los datos en la mayoría de los otros tipos de tablas, mientras que ARCHIVE no permite que nadie altere los datos que ya están en la tabla.

Busque en " Arquitectura de punto en el tiempo " o " Arquitectura de base de datos temporal "

Diseño de bases de datos: un punto en la arquitectura del tiempo

En la mayoría de las implementaciones de bases de datos relacionales. Los comandos Actualizar y Eliminar destruyen los datos que estaban allí antes de su emisión. Sin embargo, algunos sistemas requieren que ninguna información se elimine físicamente o se actualice en la base de datos. En este artículo, Arthur Fuller presenta una solución a este requisito en forma de una arquitectura de punto en el tiempo: un diseño de base de datos que permite al usuario recrear una imagen de la base de datos tal como existía en cualquier momento anterior, sin destruir La imagen actual.

Base de datos temporal

De Wikipedia, la enciclopedia libre
Base de datos temporal almacena datos relacionados con instancias de tiempo. Ofrece tipos de datos temporales y almacena información relacionada con el tiempo pasado, presente y futuro.

La idea básica de ambos es que necesita agregar datos sin eliminarlos, o almacenar datos de tal manera que pueda extraer los datos tal como existen actualmente ... o existían en una fecha y hora anterior.

pregunta relacionada aquí: cómo-crear-un-punto-en-tiempo-arquitectura-en-mysql ,