MySQL Historie für ein Objekt anlegen

pengwolf

Mitglied
Hi,

Es geht um die Historie bei einer Veraltung von Exponaten in einer Datenbank. Wir haben mehrere Tabellen, die mit einbezogen werden müssen.

Exponat = (id: Key, name, beschreibung, sektions_id, kategorie_id)
Sektion = (id: key, name, beschreibung, parent_id, museum_id)
Categorie = (id: Key, name)
Bild = (id: Key, name, file:Blob)
Ausgeliehen = (id: Key, exponat_id, ausstellung_id)
Ausstellung = (id: Key, addresse_id, name, beschreibung)

(Erstmal die Wichtigsten)

Nun soll es möglich sein, dass man in einer Historie nachsehen kann was mit diesem Exponat passiert ist. Also wann wurde der Name geändert. Wie lange war das Exponat in einer bestimmten Ausstellung und so weiter. Es muss nicht gespeichert werden, wer es geändert hat, da es atm ein Single-User-Programm ist. Wir haben schon verschiedene Herangehensweisen versucht. So haben wir uns z.B. am Anfang überlegt, dass man die Historie so anlegt:

Historie = (id: Key, exponat_id, date, sektion, ausstellung)

So könnte man speichern, wann das Exponat wo war. Also Ausstellung, oder Sektion. Und wenn es wechselt, dann trägt man neu ein.

Dann kam die Anforderung, dass man auch Namen und Beschreibung etc. auslesen muss. Da kamen wir auf die Idee eine History-Tabelle anzulegen, wo der ganze Tupel getriggert wird. Sodass man mit dem dazugehörigen Datum immer nachvollziehen kann, wie das Exponat aussah. Das ist aber bei häufigen Änderungen sehr schnell sehr Speicherlastig, weil ja die Exponate mehrmals gespeichert werden.

Nun hatten wir überlegt, ob man nicht immer nur die Änderungen in der History-Tabelle hinterlegt und die anderen Felder null setzt.

Also würden für unsere Exponate die Historie im Moment so aussehen:

Ausgeliehen = (id: Key, exponat_id, ausstellung_id, ausgeliehen: Date, zurueck: Date)
Historie_Objekt = (id: key, date, exponat_id, name, beschreibung, sektion_id, kategorie_id)

Wir müssen aber auch angeben können, in welcher Sektion das Objekt war, wenn diese Sektion oder diese Kategorie schon gelöscht wurde. Weswegen wir überlegt hatten ein Feld mit "deleted: Date" in den betroffenen Tupeln zu erzeugen. So ist gewährleistet dass immer alle Daten vorhanden sind. Und wir dort auch mit dem eintragen des Datums in deleted nachvollziehen können, wann es gelöscht wurde.

Da ist uns ganz kurz noch die Idee gekommen das in einem Hardcodierten String zu speichern. Das haben wir aber ganz schnell wieder verworfen.

Würde mich freuen wenn ihr dazu ein paar Infos aus der Praxis hättet, wie man das elegant lösen könnte.

Schon einmal vielen Dank!
 
Würde mich freuen wenn ihr dazu ein paar Infos aus der Praxis hättet, wie man das elegant lösen könnte.

Eine gute, revisionssichere Historie ist immer bisserl schmutzig und Eleganz ist meisstens fehl am Platz.

Besonders nervig wird es, wenn (wie in Deinem Fall) der Stammsatz über viele Joins zusammengebaut wird denn in diesem Fall muss dann auch von den relevanten Seitentabellen auch eine Historie gefüllt werden (zb. jemand benennt die Kategorie um und in 3 Jahren fragt einer "Wie hiess das früher?")

Ich würde mir (wie von euch auch schon angedacht) sämtliche relvanten Spalten herausschreiben, damit eine recht breite Tabelle mit "yymmddhhmmss, spalte, spalte ...." anlegen und bei jeder Änderung nur die geänderten Spalten wegschreiben (die anderen setzt man auf NULL womit das Problem mit der dicken Bilddatei wegfällt).

Bernd
 
Wie oft wird geändert, und wie lange muss die Historie vorgehalten werden?
Eine Möglichkeit wäre auch die Verwendung von "gültig ab" und "gültig bis" Spalten, eine andere eine Journaltabelle je Entität welche mittels INSERT/UPDATE-Trigger auf der DB befüllt wird, oder durch Programmlogik (würde Trigger vorziehen zwecks revisionssicherer).
Problematisch könnte es dann nur werden mit der Darstellung der Daten. Je nach Darstellungsform stellt einen diese Herangehensweise vor Probleme.... (z.B. wenn man mit dem Exponat einsteigt und dann "über alles" eine Art Zeitstrahl bilden muss).
 
Wie lange die Historie angezeigt werden muss wissen wir nicht. Müssen wir nochmal mit unserem Tutor/Kunden klären.

Werde mir den Link dazu mal angucken. Danke
 

Zurück
Oben