Comment appliquer une table de base de données en écriture unique puis en lecture seule dans SQL?

Est-ce même possible?

Mon cas d'utilisation est une table de grand livre, avec la condition qu'une fois un enregistrement créé, il doit être en lecture seule, c'est-à-dire que personne ne doit pouvoir le modifier ou le supprimer. Cela ne s'applique qu'à la table du grand livre et aux tables ayant une relation directe avec elle - il existe d'autres tables dans le même schéma qui seront mises à jour / supprimées normalement.

D'après ce que je comprends, à des fins d'intégrité des données, ce type de contraintes devrait être appliqué à la couche de base de données, mais je ne trouve pas de moyen propre et largement accepté de le faire - est-ce un cas d'utilisation où je ferais mieux de le faire dans la couche application?

L'idéal serait de trouver un moyen de le faire en langage SQL simple, afin d'être indépendant de la plate-forme de base de données utilisée, car cela peut être sujet à changement, mais je me rends compte que cela peut être trop demander, donc si cela a pour être dépendant de la plate-forme, une certaine saveur de MySQL est préférée.

Merci!

Je vois au moins deux façons d'y parvenir. La première approche est de ne pas accorder DELETEet UPDATEprivilèges sur ces tables d' écriture une fois, ou, d'ailleurs, tous les privilèges en dehors de INSERTet SELECT, ainsi que permettant aux utilisateurs d'insérer dans ou choisir parmi eux.

Une autre option consiste à définir BEFORE UPDATEet BEFORE DELETEdéclencheurs sur ces tables et utiliser la SIGNALdéclaration à soulever une exception dans le corps de déclenchement, ce qui empêcherait respectivement les mises à jour et les suppressions.

Les autorisations semblent être le choix évident - mais vous pouvez également utiliser le moteur de stockage ARCHIVE . Ce moteur de table est conçu pour enregistrer de grandes quantités de données qui ne changeront pas:

Le moteur ARCHIVE prend en charge INSERT, REPLACE et SELECT, mais pas DELETE ou UPDATE. Il prend en charge les opérations ORDER BY, les colonnes BLOB et, fondamentalement, tous les types de données sauf spatiaux (voir Section 11.5.1, «Types de données spatiales»). Le moteur ARCHIVE utilise un verrouillage au niveau des lignes.

La différence avec les autorisations est que quelqu'un avec des privilèges étendus pourrait toujours modifier les données sur la plupart des autres types de table, tandis que ARCHIVE ne permet à personne de modifier les données qui sont déjà dans la table.

Regardez dans « Point in Time Architecture » ou « Temporal Database Architecture »

Conception de base de données: une architecture à un moment précis

Dans la plupart des implémentations de bases de données relationnelles. Les commandes de mise à jour et de suppression détruisent les données qui étaient présentes avant leur émission. Cependant, certains systèmes nécessitent qu'aucune information ne soit physiquement supprimée ou mise à jour dans la base de données. Dans cet article, Arthur Fuller présente une solution à cette exigence sous la forme d'une architecture Point-in-Time: une conception de base de données qui permet à un utilisateur de recréer une image de la base de données telle qu'elle existait à tout moment antérieur, sans détruire l'image actuelle.

Base de données temporelle

À partir de Wikipédia, l'encyclopédie gratuite
Base de données temporelle stocke des données relatives aux instances de temps. Il propose des types de données temporelles et stocke des informations relatives au temps passé, présent et futur.

L'idée de base des deux est que vous devez soit ajouter des données sans les supprimer, soit les stocker de manière à pouvoir extraire les données telles qu'elles existent actuellement ... ou existaient à une date / heure précédente.

question connexe ici: comment créer une architecture à point dans le temps dans mysql ,