Nous implémentons un nouveau système utilisant Java/Spring/Hibernate sur PostgreSQL. Ce système doit faire une copie de chaque enregistrement dès qu'une modification/suppression est effectuée sur le (s) enregistrement (s) dans les tableaux. Plus tard, la ou les tables d'audit seront interrogées par les rapports pour afficher les données aux utilisateurs. Je prévoyais d'implémenter cette fonction d'audit/de versionnage en ayant un déclencheur sur la ou les tables qui ferait une copie de la ligne modifiée (ligne supprimée) "TO" une TABLE appelée ENTITY_VERSIONS qui aurait environ 20 colonnes appelé col1, col2, col3, col4, etc qui stockent les colonnes de la Table (s) ci-dessus; Cependant, le problème est que s'il y a plus d'une table à versionner et seulement 1 table TARGET (ENTITY_VERSIONS) pour stocker toutes les versions des tables, comment puis-je concevoir la table TARGET?Comment implémenter l'audit/le versionnage des modifications de table sur PostgreSQL
OU est-ce mieux qu'il y ait une COPIE de la table VERSION pour chaque table qui a besoin de la gestion des versions?
Ce sera un bonus si certains pointeurs vers PostgreSQL Triggers (et le processus Stored Procedure associé) pour implémenter l'auditing/versioning peuvent être partagés.
P.S: J'ai regardé Suggestions for implementing audit tables in SQL Server? et un peu comme la réponse, sauf que je ne sais pas quel type devrait OldValue et NewValue être?
P.P.S: Si les tables utilisent des SUPPRIMES SOFT (suppressions fantômes) au lieu des suppressions HARD, vos conseils changent-ils?
+1 merci. Je me demande quelle est la force d'avoir un «TABLEAU d'audit GLOBAL» par rapport à un «Tableau d'audit pour chaque tableau», sans interroger les données pour les rapports? – anjanb
Si vous réussissez à avoir une table d'audit GLOBAL, je prévois ALOT de type casting. Je veux dire ... dans quel type stockez-vous toutes les colonnes? – rfusca
rfusca: à droite. oui, c'était aussi mon doute! – anjanb