nicht angemeldet
Hi André,
Das ist so weit schon ok! Du solltest noch eine weitere Spalte hinzufügen, die kennzeichnet, welche Version die aktuellste ist.
id | item | lastchange | name | content | current_version
1 102 2006-11-08 foo foobar 0
2 102 2006-11-09 foo barfoo 1
3 102 2006-11-11 foobar bar 0
Wieso das denn? Das ist doch völlig unpraktisch - was wenn du aufgrund eines Datencrashs mal in mehreren Datensätzen curren_version auf 1 stehen hast? Dann hast du ein Problem.
Die letzte Version ist doch in diesem Beispiel eindeutig die, mit dem größten Wert bei lastchange. Ich würde das Feld lastchange übrigens in created umbenennen - das würde den Sinn auch mehr verdeutlichen, wo created am größten ist, dabei handelt es sich um die neueste Version. Es empfiehlt sich natürlich hier eine DATETIME Spalte und nicht DATE Spalte zu nehmen.
Wenn allerdings nur mit der aktuellen Version gearbeitet wird und auf die alten Versionen im Normalfall nicht mehr zugegriffen werden muss, so würde ich aus Performance Gründen die alten Versionen nicht in der Tabelle speichern, welche die aktuellen Versionen enthält - Wozu immer alle Versionen durchgehen, wenn man (wie gesagt im Normalfall) eh immer nur die neueste will? Und damit sind wir dann ziemlich genau bei dem Vorschlag von Hamstar angekommen.
Die Verbindung zwischen den beiden Tabellen, gemäß Hamstars Vorschlag {%DATA%} und {%DATA%}_HISTORY ließe sich hier ja prima über die Spalte item erzeugen. In der Tabelle {%DATA%} ließe sich diese Spalte vermutlich gut als Primärschlüssel einbauen, sodass jeder neuer Eintrag (der hier einer neuen "Seite" oder "Information" entspricht) auch eine (neue) einmalige ID erhält. In {%DATA%}_HISTORY kann man dann einfach einen Index über item anlegen.
Viele Grüße aus Kanada,
~ Dennis.