nicht angemeldet
Hi,
das es langsam läuft, liegt vielleicht einfach nur daran, dass die Spalte "Version" nicht von einem Index erfasst ist und dadurch nicht schneller auf die Werte zugriffen werden kann.
Alle Versionen von allen Dokumenten inkl. deren "Inhalt" in einer einzigen Tabelle zu verwalten, ist genauso legitim, wie eine Tabelle für den Versionsbaum und eine Tabelle für den Inhalt zu verwenden.
Bei der Variante mit einer Tabelle solltest du natürlich auf einen sinnvollen Primärschlüssel bzw. einen sinnvollen UNIQUE-Schlüssel achtgeben, der ua. auch die Versionsnummer beinhaltet.
Es gibt dann verschiedene Ansätze die Versionsverwaltung zu implementieren, was ua. auch davon abhängt, wie die Versionsverwaltung funktionieren darf: linear oder verzweigt, mit Vorwärtszeiger (Folgeversion) oder Rückwärtszeiger (Vorgängerversion). Auch hängt es von den Möglichkeiten des Datenbanksystems ab.
Du kannst jeweils die Versionsnummer für neue Versionen eines Dokuments inkrementieren (nicht exkrementieren bitte ;)), oder die aktuellste Version (siehe globe's Beitrag) immer mit "0" führen und alle älteren versionen dann jeweils um 1 updaten (also zurückverlagern).
Ein mögliches Designmuster für Baumstrukturen in rleationalen Datenbanken sind auch "Nested Sets" welche etwas schreiblastig sind (1 Insert mit mehreren Updates) und dafür recht einfach zu lesen und zu analysieren sind. Wenn also nicht zuviel Schreiblast erfolgt, dann könnte sich das durchaus eignen.
CVS bzw Subversion haben z.b. eine etwas andere Struktur mit ua. mehrteiligen Revisionsnummern die auch eine Verzweigung darstellen können, die man natürlich auch implementieren könnte. Lineare Versionen haben fortlaufende Nummern, verzweigte Versionen bekommen dann eine Unterrevision und laufen dort auch wieder linear:
1 -> 2
1.1 -> 1.2
1.1.1
.... 1.2.23
Dazu müsstest du dann eine gewisse Logik schreiben, die solche mehrteiligen Revisionsnummern verarbeiten kann.
Du siehst, viele Wege führen nach Rom. :)
Gruss, Frank