Meine Wahl wäre eine Variation von Ansatz 2. Fett zeigt Felder im Primärschlüssel an.
- Sie fügen jeden Artikel in eine Tabelle
articles_versioned
ein (ID , Zeitstempel , Name, Text) - Ihre zweite Tabelle ist
articles
(ID , Zeitstempel, [Name, Text]). Beachten Sie, dass timestamp nicht primär ist; Name und Text können repliziert werden, oder Sie können einen Join mitarticles_versioned
verwenden (was schnell sein wird, da id und timestamp diearticles_versioned
sind Primärschlüssel) articles_versioned
hat einen Trigger beim Einfügen, der die gerade eingefügte Zeile nimmt und sie aufarticles
repliziert- Um eine bestimmte Version eines Artikels wiederherzustellen, ändern Sie die
articles
Tabelle.
Die Vorteile dieses Ansatzes sind:
- Sie erhalten kostenlos eine weitere Information (Datum und Uhrzeit des Artikels) in Ihrer Tabelle, die Sie eventuell sowieso benötigen
- Sie müssen die Datenbank nicht abfragen, um das aktuelle Datum zu erhalten. Wenn Sie Version verwenden, müssen Sie.
- Ihr Code muss den Artikel nicht in zwei Tabellen einfügen. Sie fügen einfach
articles_versioned
ein und lesen Sie ausarticles
, kümmert sich die db um die Datenmigration, während Sie sie über den Trigger einfügen, wodurch Konsistenzprobleme vermieden werden.
Nachteile
- In einer stark nebenläufigen Umgebung können zwei Versionen gleichzeitig eingefügt werden, sodass eine davon fehlschlagen kann. Dies sollte kein Problem sein, wenn von Benutzern geschriebene Artikel eingefügt werden (es ist heutzutage höchst unwahrscheinlich, wenn man die Genauigkeit der Zeitstempel berücksichtigt). Wenn Sie den Zeitstempel nicht in Ihrem
INSERT
angeben -Anweisung, aber stattdessen das datetime-Feld so einstellen, dass es die aktuelle Zeit als Standardwert hat, können Sie dieses Problem vollständig vermeiden.
Um den Rest deiner Frage zu beantworten. Ansatz 1 führt nicht zu längeren Abfragen, solange Sie einen Index zum Status hinzufügen. Dies ist nur dann sinnvoll, wenn Sie dazu neigen, viele verschiedene Versionen jedes Artikels zu haben; Solange Sie im Durchschnitt 2 Versionen pro Artikel oder weniger haben, wird Sie der Index nur verlangsamen, und Ansatz 2 wäre sowieso nicht vernünftig schneller (obwohl ich meinen Ansatz immer noch empfehlen würde, weil er den Code vereinfacht, da das Wiederherstellen einer Version dies tut Schaltstatus für zwei Zeilen nicht erforderlich).
Zugehörige Ressourcen wie Bilder sollten einer ähnlichen Versionierung folgen. Ich nehme an, Sie speichern sie im Dateisystem. Anstatt sie unter ihrem richtigen Namen zu speichern, verwenden Sie eine Tabelle (id , Bildname), um jedem Bild eine ID zuzuweisen, und speichern Sie das Bild dann als -id-.jpg
. Das Feld image_name zeigt Ihnen, wie der ursprüngliche Dateiname lautete (falls es Sie interessiert). Auf diese Weise können Sie Bilder genauso versionieren wie Artikel, und in Artikeln würden Sie so etwas wie <img src="-id-.jpg">
verwenden , von der Sie wissen, dass sie für immer verfügbar bleiben wird.