Ich habe eine imports Tabelle, die Informationen über Dateiimport enthält, die getan werden: idimport (SERIAL PRIMARY KEY), Dateinamen, Importdatum usw.Referenzielle Integrität: Alle Kinder löschen, aber nicht den übergeordneten [PostgreSQL]
Mehrere Tabellen habe ein Feld idimport INTEGER REFERENCES imports(idimport) ON DELETE CASCADE.
Um eine Datei "unimport" zu machen, muss ich nur die Zeile in der Tabelle imports LÖSCHEN.
Das Problem, mit dem ich konfrontiert bin, ist, dass einige Benutzer mir sagen, dass sie definitiv eine Datei importiert haben, aber keine Spur der importierten Daten finden. Normalerweise haben sie die Datei nicht importiert und vergessen, sie erneut zu importieren, aber ich habe keinen Beweis dafür (außer der fehlenden idimport, die bei weitem nicht genug ist).
So würde ich gerne die Importe, die gelöscht wurden, verfolgen. Idealerweise möchte ich, dass PostgreSQL alle untergeordneten Zeilen löscht, die übergeordnete Zeile (imports) behält und diese Zeile als gelöscht markiert, den Benutzer, der sie gelöscht hat und wann die Löschung vorgenommen wurde (und möglicherweise ein Grund für die Löschung).
Die Idee, die ich hier habe, ist ein ON DELETE Trigger erstellen, die die „interessanten“ Felder in der imports Tabelle auswendig lernen würde, lassen Sie den Löschvorgang laufen und erstellen eine imports Reihe mit den interessanten Bereichen (einschließlich der idimport) und diejenigen, Ich will hinzufügen.
Aber ich möchte sowohl "vor" (auswendig lernen) und "nachher" (die Zeile neu erstellen) Aktionen, so dass es zwei Auslöser sein würde und ich weiß nicht, wie ich sie kommunizieren könnte (die interessanten Felder).
Natürlich könnte ich entweder tun, um diese clientseitige oder eine gespeicherte Prozedur erstellen, aber ich würde eine vollständig integrierte Lösung (Arbeiten mit DELETE FROM imports WHERE idimport=12)
Sie können auf die gesamte gelöschte Zeile in einem 'after' Trigger zugreifen, obwohl der' alte' Datensatz (es gibt keine Notwendigkeit, etwas zu merken) – pozs
Ich würde wahrscheinlich eine neue separate Tabelle verwenden, um gelöschte Zeilen zu archivieren. Dies könnte in einem einzigen einfachen Auslöser implementiert werden. – klin
Sie suchen nach einem Audit-Trigger. Siehe [hier] (https://eager.io/blog/audit-postgres/) oder [hier] (https://www.garysieling.com/blog/auditing-data-changes-postgres) oder [hier] (https://wiki.postgresql.org/wiki/Audit_trigger_91plus) oder [hier] (http://okbob.blogspot.de/2015/01/most-simply-implementation-of-history.html) oder [hier] (http://8kb.co.uk/blog/2015/01/19/copying-pavel-stehules-simple-history-table-but-with-the-jsonb-type/) –