Stiamo implementando un nuovo sistema utilizzando Java/Spring/Hibernate su PostgreSQL. Questo sistema deve fare una copia di Every Record non appena una modifica/cancellazione viene effettuata sui record nelle Tabelle. Successivamente, le tabelle di controllo verranno interrogate dai report per visualizzare i dati agli utenti.Come implementare il controllo/versioning delle modifiche della tabella su PostgreSQL
Avevo intenzione di implementare questa funzione di controllo/versione avendo un trigger sulla tabella (s) che farebbe una copia della riga modificata (riga eliminata) "TO" una TABELLA chiamata ENTITY_VERSIONS che avrebbe circa 20 colonne chiamato col1, col2, col3, col4, ecc. che memorizzerebbe le colonne dalla Tabella (e) precedente; Tuttavia, il problema è che se è presente più di 1 tabella per la versione e SOLO 1 tabella TARGET (ENTITY_VERSIONS) per memorizzare tutte le versioni delle tabelle, come si progetta la tabella TARGET?
OPPURE è meglio che ci sia una COPIA della tabella VERSIONE per ogni tabella che richiede il controllo delle versioni?
Sarà un bonus se alcuni puntatori verso i trigger di PostgreSQL (e il codice di stored procedure associato) per l'implementazione del controllo/versioning possono essere condivisi.
P.S: ho guardato Suggestions for implementing audit tables in SQL Server? e un po 'come la risposta, tranne NON vorrei sapere che tipo dovrebbe essere OldValue e NewValue?
P.P.S: Se le Tabelle utilizzano CANCELLA SOFT (eliminazioni fantasma) invece di cancellazioni HARD, è possibile modificare qualche consiglio?
+1 grazie. Mi chiedo quali sono i punti di forza di avere una "GLOBAL audit TABLE" rispetto a "Audit Table per ogni tabella" w.r.t a interrogare i dati per la segnalazione? – anjanb
Se in qualche modo riesci ad avere una tabella di controllo GLOBAL, prevedo un ALTO tipo di casting. Voglio dire ... di che tipo immagazzineresti tutte le colonne? – rfusca
rfusca: giusto. sì, quello era anche il mio dubbio! – anjanb