Strukturierung, versionierte Tabelle - schneller vs. schlicht

[Mario]

Hi globe,

Danke für deine Beispiele zum Thema!

Der aktuellste Datensatz hat dabei immer rectill = 0. Für einen einfacheren Umgang (lesen) gibt es einen VIEW: SELECT * FROM table WHERE rectill = 0;

Auf die Idee war ich gar nicht gekommen. Find ich aber wirklich raffiniert.

Ich hatte auch schon überlegt, mein versions-Feld auszusparen, denn letztlich erfüllt der lastchanged-Timestamp den selben Zweck. Andererseits muss ich die Versionsverwaltung auch irgendwo in der Benutzerschnittstelle unterbringen, und da machen sich kurz Versionsnummern (1, 2, .. 57) doch besser als lange Zeitstempel (1190712403). Aber es ist ja eh nicht so wichtig welches Feld ich nun einspanne.

Auf meinen Fall angewendet, benötige ich ja keine Zeitabschnitte, sondern einfach nur einen Indikator wie rectill=0. Ich könnte also einfach ein Feld nextversion (statt lastversion) verwenden.
Dann finde ich auch immer die aktuellste Version mit nextversion=0 oder IS NULL -- was in der DB sicher schneller geht als dutzende Vergleiche (version=lastversion?). Und obendrein spare ich mir damit die mglw. langsamen Aktualisierungen aller lastversion-Einträge bei Seitenupdates.

Der zweite Ansatz hat zwar den Nachteil, dass man auf einmal viel mehr Tabellen hat, bringt aber mehrere Vorteile mit sich. Zunächst ist die referentielle Integrität kein Problem. Auf den zweiten Blick kann man mit dieser Struktur viele Änderungsoperationen unter einer Revisionsnummer (mit lauter tollen Metadaten) ablegen (und notfalls wiederherstellen).

Hier war ich immer unsicher, ob MySQL sowas hinbekommt. Wenn die Datenbank natürlich sicherstellen kann, daß Fremdschlüssel _immer_ automatisch mit neu eingefügten oder geänderten Datensätze aktualisiert werden, wär das super.
PostgreSQL hab ich zwar hier laufen, aber bei meinem Provider nur MySQL. Und genaugenommen würd ich am liebsten SQLite ausprobieren. Und ich fürchte, es bliebe dann an mir, die Daten konsistent zu halten. Und an irgendeinem Punkt tauchen dann die Datenbank-internen Referenzschlüssel in der ganzen Applikation (oder schlimmer noch: in der Benutzeransicht) auf. Auch aus dem Grund wollte ich sowas eher ungern verwenden.

Aber das kann ich mir ja noch überlegen, und das Datenbankschema ist ja nicht in Stein gehauen. Falls die DB wirklich zu groß wird, kann man sie immernoch korrekt optimieren.

Wieauchimmer, danke erstmal für die tollen Tips!
Mario