Konzept: Versionierung von Inhalten?

[burzum]

Wie kann ich am besten Inhalte versionieren, also eine Historie der Veränderungen an einem Datensatz, am besten umsetzen? Ein Datensatz hat mehrere Felder die sich ändern können. Bei den Datensätzen handelt es sich in dem Fall um Locations, Events und der Beschreibung von archäologischen Fundstücken.

Folgende Lösung käme mir spontan in den Sinn:

Vor dem Speichern der neuen Daten den Datensatz lesen, gelesenen Datensatz neu speichern (erzeugt eine neue ID) mit Fremdschlüssel auf das Original, das Original mit der Änderung überschreiben.

Man könnte die Historie noch in einer extra Tabelle ablegen um die Orginalartikeltabelle schlanker zu halten.

Allerdings bin ich mir nicht schlüssig ob dies eine Ideallösung ist? Verbesserungsvorschläge und Ideen?

[onemorenerd]

content (cid, name, descr, ...)
revisions (rid, cid, name, descr, ...)

Ein neuer Datensatze wird in content gespeichert, bei Änderungen nach revisions verschoben und die geänderte, aktuelle Version verbleibt in content.

[burzum]

Das ist doch genau das was ich vorschlug?

[tontechniker]

content (cid, name, descr, ...)
revisions (rid, cid, name, descr, ...)

Sowas in der Art fände ich sinnvoller weil man dann die Felder von Content in nicht in mehreren Tabellen hat:

content ( cid, rid, name, dscr, ... )
revisions, ( rid, name )

[onemorenerd]

Wenn die Inhalte nur selten verändert werden, ist das okay. Aber dann verzichtet man meist ganz auf Versionierung.

Werden Inhalte sehr oft verändert, entstehen viele Revisionen. Wenn man die alle in der content Tabelle speichert, wird die schnell sehr groß. (Der Gesamt-Speicherverbrauch ist bei beiden Ansätzen gleich.)
Handelt es sich um Webseiten, werden die Inhalte sehr oft angezeigt.
Also viele Selects auf einer großen Tabelle und damit potenziell langsamerer Zugriff.

Das wäre für mich Grund genug, lieber die Spaltendefinitionen mehrmals vorliegen zu haben. Die ändern sich doch eh nur alle Jubeljahre.