Nachvollziehbare Änderungen an Daten

[sebastia...@googlemail.com]

Hallo zusammen!

Ich stehe vor folgender Aufgabe:

Auf einer Website mit diversen verschiedenen Formularen (Kundenstamm,
Produkte, ...), deren Daten in einer mySQL-Datenbank gespeichert
werden, sollen sämtliche Änderungen nachvollziehbar gespeichert sein.

Bisher werden Änderungen mit einem UPDATE-Statement einfach
gespeichert.
Problem für den Auftraggeber: Er kann nicht mehr sehen,
1. welcher Wert zuvor in der Datenbank stand
2. wer hat die Änderungen vorgenommen (also welcher auf der Website
angemeldete Benutzer)
3. wann wurde diese Änderung vorgenommen.

Und zwar soll _jede_ Änderung nachvollziehbar sein, nicht nur die
letzte. Also eine Art Historie/Verlauf.

Wie kann man dies, vor allem für beliebig viele Formulare/DB-Tabellen
am besten lösen?
Zudem sind viele Formulare über mehrere DB-Tabellen mittels
Primärschlüssel verteilt (Normalform halt).

Am einfachsten wäre es natürlich, für jede betroffene Tabelle eine
"Kopie" der Tabelle anzufertigen, in welcher bei einem Update zuerst
eine Kopie des alten Eintrags erstellt wird.
Aber dieses hat viele Nachteile:
- Immenser Overhead an Daten (z.B. falls nur ein Feld geändert wurde)
- Abhängigkeiten über Indizes
Beispiel: Es wird eine Änderung an einem Produkt vorgenommen. Dieser
Datensatz enthält u.a. die ID zu dem Hersteller. Was, wenn dieser
geändert wird oder gelöscht, etc? Dann könnte man mit den Datensatz
aus der Historie nichts mehr anfangen, da es keinen Bezug mehr gibt.
Mögliche Lösung: Sämtliche Abhängigkeiten auflösen, was z.T. über
viele Tabellen geschehen müsste (Produkt -> Hersteller -> Adresse,
Produkt -> Lieferant -> Adresse ...)
Dies wäre aber nicht nur sehr komplex, sondern würde auch einen
Overhead und eine Redundanz an Daten bedeuten, die jenseits von gut
und böse sind.
Zudem müssen neue Indizes generiert werden, um die Kopien miteinander
zu verknüpfen.

Daher bin ich diese Möglichkeit sehr kritisch gegenüber.
Hat hier jemand eine bessere Idee?

Vielen Dank!

[Axel Schwenke]

"Sebastia...@googlemail.com" <sebastia...@googlemail.com> wrote:

> Ich stehe vor folgender Aufgabe:

[permanenter Audit-Trail]

Als MySQLer fällt einem natürlich sofort das Binlog ein, in das MySQL
jede Datenänderung loggt. Allerdings hat das einen Schönheitsfehler:
MySQL loggt nicht, welcher MySQL-Account jeweils verwendet wurde.
Allerdings gibt es ab MySQL 5.5 ein API für Audit-Plugins, das diese
Information abgreifen könnte:

http://dev.mysql.com/doc/refman/5.5/en/audit-plugins.html

Viel schwerer wiegt jedoch, daß (Web-)Applikationen i.d.R. nur /einen/
MySQL-Account verwenden und der Benutzer sich nur gegenüber der
Applikation (und nicht der Datenbank) identifiziert. D.h. normaler-
weise kommen für MySQL alle Änderungen vom gleichen Account.

Was man nun machen könnte:

1. die Applikation führt ein entsprechendes Log selber. Dazu wird
einfach jedes INSERT/UPDATE/DELETE auf eine der "kritischen"
Tabellen zusammen mit Uhrzeit und Nutzername geloggt.

2. man verwendet doch das MySQL-Binlog, läßt die Applikation aber
in jedes entsprechende Statement einen SQL-Kommentar mit dem
Nutzernamen einfügen. Etwa so:
UPDATE /* App: foo, Form: bar, User: Müller */ Kunden SET ...

Ob das Ergebnis (eine laaaaange Liste SQL Statements mit Timestamps)
dem Kunden dann lesbar genug ist; und ob es ihm genügt, daß die "bevor"
Werte nur implizit da drin stehen, ist natürlich eine andere Frage.
Aber wenn man das schöner haben will, dann geht es definitiv *nur*
aus der Anwendung heraus.


Allerdings klingt das für mich nach einer typischen "Schlipsträger"
Forderung. Wahrscheinlich wird sich kein Schwein die Daten jemals
ansehen und über die anfallenden Datenmengen oder Anforderungen des
Datenschutzes (Kunde gelöscht - was ist mit den Kundendaten im Audit?)
hat auch niemand auch nur ansatzweise nachgedacht.


XL