Tabelle mitÄnderungen

[Wolfgang Hauck]

Hi Tom,

>ich habe das problem so geschildert, dass es in meiner tabelle über
>50 felder gibt, die sich verändern können. was sich dann 
letztendlich
>geändert hat, sieht man mit deiner methode nur dann, wenn man die
>felder vergleicht und die ungleichen anzeigt (auslesen, analysieren,
>ausgeben...), oder?

Nein, das stimmt nicht so. Ich bilde für solche Zwecke einfach eine
Prüfsumme aus allen Feldern und vergleiche diese mit dem Eintrag in
der Datenbank...
Stimmt die Prüfsumme nicht überein, wurde was verändert. So macht man 
das übrigens auch mit Dateien...

Nachtrag:

Wenn du beispielweise ein Formular erstellen willst in dem alle 
Änderungen die seit der Alegung des Datensatzes erolgt sind kann ich 
das bei meiner Methode durch ein einziges SQL - Statement 
realiesieren:

SELECT * from Tabelle where id = 1 OR (id_root = 1 AND id_ref = 0);

Nun habe ich im ersten Datensatz den zuerst angelegten Datensatz, im 
zweiten alle Daten mit den bis zuletzt gemachten
Änderungen...
Ich muss also nur den ersten DS mit dem zweiten vergleichen und die 
unterschiedlichen Felder farbig hervorheben...
Wurde nun z.B. eine bereits gemachte Änderung verworfen werden diese 
in meiner Fallstudie !! nicht !! hervorgehoben...
Die Änderung als auch die Verwerfung sind jedoch in der DB nach wie 
vor gespeichert...
Willst du jetzt alle Veränderungen hervorheben die seit einem 
bestimmten Datum erfolgten ist das auch mit nur einer SQL - Anweisung 
möglich...

Dies lässt sich in deinem Beispiel nur durch mehrere SQL - Statements 
realisieren. Ein weiterer Nachteil besteht bei dir darin für jedes 
veränderte Feld einen eigenen Datensatz anlegen zu müssen. Wurden in 
deinem Fall z.B. 1 Feld verändert schreibst du 50 Insert - 
Statements, ein delete - Statement und eine Update - Anweisung! Welch 
ein Aufwand! Stürzt dein Script ab ist das Chaos perfekt! Bei 100 
Änderungen am Tag kommt da ganz schön was zusammen. Und mit 
Performance hat das sicherlich überhaupt nichts zu tun. Bei meiner 
Methode werden nur ein Insert und ein Update benötigt (Die ID des 
neuen DS erhalte ich via php über mysql_insert_id). Wie bitteschön 
kannst du mit deinem Konzept feststellen wie z.B. der Status des 
Datensatzes zum sagen wir mal 15. Februar 2003 ausgesehen hat?
Noch gravierender wirkt sich dein Konzept bei nachträglichen 
Änderungen der Datenbankstruktur aus. Füg doch einfach mal ein 
weiteres Feld in deine Tabelle ein (muss ja nicht immer am Ende der 
Tabelle sein). Du musst ja irgendwie deine feld_id mit dem 
tatsächlichen Feld referenzieren (Warscheinlich noch ne Tabelle mehr 
die ausgelesen werden muss. Nach meiner Erfahrung bleibt eine 
Tabellenstruktur niemals zehn Jahre gleich (man denke nur an neue 
Steuern wie Umweltsteuer, Solidaritätszuschlag etc.) Ausserdem kannst 
du ja in deiner Referenztabelle die Änderungen nur als String ablegen 
(Einen Typ Variant gibts in keiner Datenbank)... Es ist also für 
jeden anderen Typ als String eine Typumwandlung von Nöten. Änderungen 
in einem Blob oder Textfeld lassen sich bei deiner Struktur überhaupt 
nicht archivieren es sei denn du speicherst alles in ein Text oder 
Blob. Was dann aus deiner Performance wird kannst du dir ja 
ausmalen...

Na ja wers mog...
I daads net nemma...

Viele Grüsse aus dem sonnigen Bayern

Wolfgang

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql