Verwenden der sequentiellen id wäre einfacher, da es wahrscheinlich (?) Ein Primärschlüssel ist und daher indiziert und schneller zugänglich ist. Vorausgesetzt, Sie haben user_id , können Sie schnell die letzten und vorherigen Änderungen bestätigen.
Verwenden des timestamp ist auch anwendbar, aber es ist wahrscheinlich ein längerer Eintrag, und wir wissen nicht, ob er überhaupt indiziert ist, plus das Potenzial für Kollisionen. Sie weisen zu Recht darauf hin, dass sich Systemuhren ändern können ... Während sequentielle id kann nicht.
Angesichts Ihres Updates:
Da es schwierig ist, Ihre genauen Anforderungen zu erkennen, habe ich dies als Beweis dafür eingefügt, was ein bestimmtes Projekt für über 200.000 komplexe Dokumente und Millionen von Überarbeitungen erfordert.
Aus meiner eigenen Erfahrung (Aufbau eines vollständig überprüfbaren Dokument-/Profilierungssystems) für ein internes Team von mehr als 60 Vollzeitforschern. Am Ende haben wir beide eine id verwendet und eine Reihe anderer Felder (einschließlich timestamp ), um Audit-Trailing und vollständige Versionsverwaltung bereitzustellen.
Das von uns erstellte System verfügt über mehr als 200 Felder für jedes Profil, und daher war die Versionierung eines Dokuments weitaus komplexer, als nur einen Block mit geändertem Text/Inhalt für jedes einzelne zu speichern; Dennoch kann jedes Profil als EIN Dokument bearbeitet, genehmigt, abgelehnt, rückgängig gemacht, veröffentlicht und sogar als PDF oder in einem anderen Format exportiert werden.
Was wir letztendlich taten (nach viel Strategie/Planung), war, sequentielle Versionen des Profils zu speichern, aber sie waren in erster Linie verschlüsselt auf einer id Feld .
Zeitstempel
Zeitstempel wurden auch als sekundäre Überprüfung erfasst, und wir stellten sicher, dass die Systemuhren (in einem Cluster von Servern) genau waren, indem wir Cron-Skripte verwendeten, die die Zeitausrichtung regelmäßig überprüften und bei Bedarf korrigierten. Wir haben auch Ntpd verwendet Uhrdrift zu verhindern.
Andere erfasste Daten
Weitere für jede Bearbeitung erfasste Daten waren (aber nicht beschränkt auf):
User_id
User_group
Action
Approval_id
Es gab auch andere Tabellen, die interne Anforderungen erfüllten (einschließlich automatisch generierter Anmerkungen für die Dokumente) – da ein Teil der Profilbearbeitung unter Verwendung von Daten von Bots (erstellt mit NER/maschinellem Lernen/KI) erfolgte, aber eine Genehmigung von einem der erforderlich war das Team, bevor Änderungen/Aktualisierungen veröffentlicht werden konnten.
Es wurde auch ein Aktionsprotokoll aller Benutzeraktionen geführt, sodass man im Falle eines Audits die Aktionen eines einzelnen Benutzers einsehen konnte – selbst wenn er nicht die Berechtigung hatte, eine solche Aktion auszuführen, wurde sie dennoch protokolliert .
In Bezug auf die Migration sehe ich darin kein großes Problem, da Sie die ID-Sequenzen beim Verschieben / Dump / Übertragen von Daten problemlos beibehalten können. Vielleicht besteht das einzige Problem darin, dass Sie Datensätze zusammenführen müssen. In diesem Fall könnten Sie jederzeit ein Migrationsskript schreiben - daher halte ich diesen Nachteil aus persönlicher Sicht für etwas geringer.
Es könnte sich lohnen, sich die Stack Overflow-Tabellenstrukturen für den dortigen Daten-Explorer anzusehen (der ziemlich ausgefeilt ist). Sie können die Tabellenstruktur hier sehen:https://data.stackexchange.com/stackoverflow/query /neu , die aus einer Frage zu Meta stammt:How does SO store Überarbeitungen?
Als Revisionssystem funktioniert SO gut und die Markdown-/Revisionsfunktionalität ist wahrscheinlich ein gutes Beispiel dafür.
