Struktur der Audit-Tabelle

9

Ich erstelle Audit-Tabellen für meine Datenbank und muss auswählen, welcher Stil implementiert werden soll. Ich erwäge derzeit drei Optionen, die alle mit Triggern gefüllt werden:

  1. Eine einzelne Tabelle mit den Feldern id | Tabelle | Spalte | Reihe | alter_wert | neuer_Wert | Zeitstempel | Benutzeridentifikation. Dies würde alle Änderungen an allen Tabellen an einem einzigen Ort verfolgen und den Vorteil haben, die Anzahl der Tabellen zu minimieren. Es macht die Abfrage ein wenig schwierig, aber nicht unmöglich.
  2. Mehrere Tabellen wie # 1, außer ohne die Tabellenspalte. Dies würde die Änderungen von jeder Tabelle in ihre eigene Verlaufstabelle aufteilen.
  3. Mehrere Tabellen, die das Schema der zu überwachenden Originaltabellen spiegeln. Dies würde die Trigger viel einfacher zu schreiben machen, würde die Wiederherstellung der Daten einfacher, wenn jemand zu einem bestimmten Datensatz zurückkehren wollte, aber auf Kosten des Speichers kommen würde, als jedes Feld, auch wenn es nicht geändert hätte, würde dupliziert werden, möglicherweise mehrere Male. Außerdem würde es schwierig sein, genau zu wissen, welche Felder von einer Version zur nächsten geändert wurden.

Jede dieser drei Optionen ist machbar, und soweit ich das beurteilen kann, gibt es keine Funktionalität, die man anbietet, die in einem anderen unmöglich ist. Also muss es etwas geben, das ich nicht in Betracht ziehe, oder ein Muster, das mehr Standard ist. Wenn es einen Unterschied macht, muss diese Lösung sowohl für mysql als auch für sql server funktionieren (obwohl ich die Besonderheiten des Codes später ausarbeiten kann).

    
Bob Baddeley 18.11.2010, 21:36
quelle

3 Antworten

5

Audit-Tabellen werden sehr schwer getroffen, Sie wollen nicht nur eine Tabelle für alle Auditing-Vorgänge oder Sie werden blockiert.

Wir machen etwas wie Nummer zwei, außer dass wir zwei Tabellen pro Tabelle haben (eine, die die Änderungen speichert und eine, die die tatsächlichen Daten speichert. Dies macht es einfach, alle Datensätze zu finden, die in einem Amillion-Datensatz gespeichert sind Instanz, da sie alle in derselben Instanz sind, was bedeutet, dass wir Skripts erstellen können, wenn neue Tabellen hinzugefügt werden.

Im zweiten Fall würde ich vorschlagen, einen Proc zu schreiben, um einen bestimmten Datensatz wiederherzustellen, so dass die Wiederherstellung einfach ist und Sie es nicht jedes Mal herausfinden müssen.

    
HLGEM 18.11.2010, 21:42
quelle
1

Keine Antwort, nur weitere Fragen: Was ist der Zweck Ihrer Audit-Tabellen? Warum willst du sie, brauchst du sie oder musst du sie haben? Wie werden sie genutzt, welche Fragen werden sie beantworten oder welche Situationen werden sie ansprechen? Wie oft oder selten werden sie benutzt? Wie lange müssen Sie diese Daten verfügbar halten und wie werden sie nach dem Ablaufdatum gelöscht oder archiviert?

Die beiden vorhergehenden Antworten [theChrisKen, HLGEM] stimmen dem noch nicht zu - basierend auf dem, woran sie vorher gearbeitet haben - würde ich wetten, dass beide korrekt sind. Wenn Sie darüber nachdenken, wie diese verwendet werden und welche Leistungsanforderungen für diese Verwendung gelten, können Sie damit ermitteln, welches Modell für Ihre Situation am besten geeignet ist.

    
Philip Kelley 18.11.2010 21:54
quelle
0

Ich würde die Nummer 1 wählen. Nummer 2 wäre schwer zu pflegen, wenn Sie zusätzliche Felder zu Ihrem Tracking hinzufügen und fügt sehr wenig neben dem Entfernen der Notwendigkeit einer WHERE-Tabelle =? Klausel. Nummer 3 ist Overkill. Dafür gibt es Backups.

    
theChrisKent 18.11.2010 21:41
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Öffentliche Verkehrsmittel mit Bussen in der Stadt