Brug af det sekventielle id ville være enklere, da det sandsynligvis(?) er en primær nøgle og dermed indekseret og hurtigere at få adgang til. Forudsat at du har user_id , kan du hurtigt sikre dig de sidste og tidligere redigeringer.
Brug af timestamp er også anvendelig, men det er sandsynligvis en længere indgang, og vi ved ikke, om det overhovedet er indekseret, plus potentialet for kollisioner. Du påpeger med rette, at systemure kan ændre sig... Hvorimod sekventiel id 's kan ikke.
I betragtning af din opdatering:
Da det er svært at se, hvad dine præcise krav er, har jeg inkluderet dette som bevis på, hvad et bestemt projekt krævede for mere end 200.000 komplekse dokumenter og millioner af revisioner.
Fra min egen erfaring (opbygning af et fuldt auditerbart doc/profileringssystem) for et internt team på mere end 60 fuldtidsansatte forskere. Vi endte med at bruge både et id og en række andre felter (inklusive timestamp ) for at give audit-trailing og fuld versionering.
Systemet, vi byggede, har mere end 200 felter for hver profil, og derfor var versionering af et dokument langt mere komplekst end blot at gemme en blok med ændret tekst/indhold for hver enkelt; Alligevel kunne hver profil redigeres, godkendes, afvises, rulles tilbage, offentliggøres og endda eksporteres som enten PDF eller andet format som ET dokument.
Det, vi endte med at gøre (efter en masse strategi/planlægning) var at gemme sekventielle versioner af profilen, men de var nøglet primært på et id felt .
Tidsstempler
Tidsstempler blev også fanget som en sekundær kontrol, og vi sørgede for at holde systemure nøjagtige (blandt en klynge af servere) ved at bruge cron-scripts, der tjekkede tidsjusteringen regelmæssigt og rettede dem, hvor det var nødvendigt. Vi brugte også Ntpd for at forhindre urdrift.
Andre registrerede data
Andre data, der er registreret for hver redigering, inkluderede også (men ikke begrænset til):
User_id
User_group
Action
Approval_id
Der var også andre tabeller, der opfyldte interne krav (herunder automatisk genererede annoteringer til dokumenterne) - da en del af profilredigeringen blev udført ved hjælp af data fra bots (bygget ved hjælp af NER/machine learning/AI), men med godkendelse påkrævet af en af teamet før redigeringer/opdateringer kunne publiceres.
Der blev også ført en handlingslog over alle brugerhandlinger, så man i tilfælde af en revision kunne se på en individuel brugers handlinger - selv når de ikke havde tilladelser til at udføre en sådan handling, blev den stadig logget .
Med hensyn til migrering ser jeg det ikke som et stort problem, da man sagtens kan bevare id-sekvenserne ved at flytte/dumpe/overføre data. Måske er det eneste problem, hvis du havde brug for at flette datasæt. Du kan altid skrive et migrationsscript i den begivenhed - så fra et personligt perspektiv anser jeg den ulempe for at være noget mindre.
Det kan være værd at se på Stack Overflow-tabelstrukturerne for deres data explorer (som er rimeligt sofistikeret). Du kan se tabelstrukturen her:https://data.stackexchange.com/stackoverflow/query /ny , som kommer fra et spørgsmål om meta:Hvordan gemmer SO revisioner?
Som revisionssystem fungerer SO godt, og markdown-/revisionsfunktionen er nok et godt eksempel at vælge over.