Création efficace d'enregistrements de base de données en lecture seule

Question

Comment puis-je m'assurer que les données spécifiques de la base de données ne sont plus modifiées?

Nous travaillons avec TSQL. Dans la base de données, nous stockons les révisions de contrat. Ceux-ci ont un statut: brouillon/actif. Lorsque le statut est activé, la révision peut ne plus jamais être modifiée. Une révision peut avoir 8 modules actifs (chacun avec sa propre table), chacun avec leurs propres paramètres et sous-tables. Cela crée un arbre entier de tables avec des enregistrements qui ne peuvent plus jamais changer lorsque la révision du contrat a été définie sur active.

Idéalement, je marquerais simplement ces enregistrements en lecture seule. Mais une telle chose n'existe pas aujourd'hui. La prochaine chose qui vient à l'esprit sont les déclencheurs. Je dois donc ajouter ces déclencheurs à un grand nombre de tables, toutes liées à la révision du contrat.

Maintenant peut-être il existe d'autres approches, comme une base de données uniquement pour l'archivage sur lequel l'utilisateur a seulement des droits d'insertion. Ainsi, lorsqu'une révision de contrat est devenue active, elle est déplacée d'un DB vers le DB d'archivage (l'insertion est autorisée). Et ne peut plus jamais être modifié (DENY UPDATE | DELETE).

Mais peut-être y at-il d'autres options plus ingénieuses auxquelles je n'ai pas pensé, et vous l'avez fait. Peut-être y compris le CLR ou quoi d'autre.

Alors, comment est-ce que je peux créer une arborescence d'enregistrements dans notre base de données TSQL qui est la plus simple, facile à comprendre, à configurer rapidement et qui peut être appliquée de la manière la plus générique?

Answer 1

Qu'est-ce que vous fassiez (triggers, les droits accordés ...) peuvent être surmontés par un utilisateur avec des droits plus élevés, cela vous en être sûr ...

Est-ce juste pour archiver ces données?

Une idée qui m'est venue à l'esprit était de créer un fichier XML imbriqué avec toutes les données à l'intérieur d'une grande structure et de le mettre quelque part dans une table d'appoint. Créez un INSTEAD OF UPDATE,DELETE TRIGGER où vous ne faites rien. Laissez ces tables être 1:1.

Vous pouvez toujours travailler avec ces données, mais pas aussi rapidement que si elles étaient lues à partir de tables physiques.

Si vous le souhaitez, vous pouvez même convertir le XML en une chaîne et calculer un code de hachage, que vous stockez dans un endroit différent pour vérifier les manipulations.

L'ensemble du processus peut être effectué dans un seul appel de procédure stockée.