Pomocí sekvenčního id by bylo jednodušší, protože je to pravděpodobně (?) primární klíč, a tudíž indexovaný a rychlejší přístup. Vzhledem k tomu, že máte user_id , můžete rychle potvrdit poslední a předchozí úpravy.
Pomocí timestamp je také použitelný, ale pravděpodobně se bude jednat o delší položku a nevíme, zda je vůbec indexována, plus možnost kolizí. Správně poukazujete na to, že systémové hodiny se mohou měnit... Zatímco sekvenční id 's nemůže.
Vzhledem k vaší aktualizaci:
Protože je obtížné zjistit, jaké jsou vaše přesné požadavky, uvedl jsem to jako důkaz toho, co konkrétní projekt vyžaduje pro 200 000+ komplexních dokumentů a miliony revizí.
Z vlastní zkušenosti (budování plně auditovatelného doc/profiling systému) pro interní tým více než 60 výzkumníků na plný úvazek. Nakonec jsme použili oba id a řada dalších polí (včetně timestamp ), aby poskytoval audit-trailing a plnou verzi.
Systém, který jsme vytvořili, má více než 200 polí pro každý profil, a proto bylo vytváření verzí dokumentu mnohem složitější než pouhé ukládání bloku změněného textu/obsahu pro každý z nich; Přesto lze každý profil upravit, schválit, zamítnout, vrátit zpět, publikovat a dokonce exportovat buď jako PDF nebo jiný formát jako JEDEN dokument.
Nakonec jsme (po spoustě strategie/plánování) uložili sekvenční verze profilu, ale ty byly klíčovány primárně na id pole .
Časová razítka
Časová razítka byla také zachycena jako sekundární kontrola a zajistili jsme, aby byly systémové hodiny přesné (mezi shlukem serverů) pomocí cron skriptů, které pravidelně kontrolovaly časové zarovnání a v případě potřeby je opravovaly. Také jsme použili Ntpd abyste zabránili posunu hodin.
Další zaznamenaná data
Další data zachycená pro každou úpravu také zahrnovala (ale nejen):
User_id
User_group
Action
Approval_id
Existovaly také další tabulky, které splňovaly interní požadavky (včetně automaticky generovaných anotací k dokumentům) – protože některé úpravy profilu byly provedeny pomocí dat od robotů (vytvořených pomocí NER/strojového učení/AI), ale bylo vyžadováno schválení jedním z tým před zveřejněním úprav/aktualizací.
Protokol akcí byl také uchováván o všech akcích uživatele, takže v případě auditu bylo možné se podívat na akce jednotlivého uživatele - i když neměl oprávnění k provedení takové akce, byl stále zaznamenán .
S ohledem na migraci to nevidím jako velký problém, jelikož při přesunu/vysypání/přenosu dat můžete snadno zachovat id sekvence. Snad jediným problémem je, pokud potřebujete sloučit datové sady. V takovém případě byste vždy mohli napsat migrační skript - takže z osobního hlediska považuji tuto nevýhodu za poněkud zmenšenou.
Možná by stálo za to podívat se na struktury tabulky Stack Overflow pro průzkumník dat (který je přiměřeně sofistikovaný). Strukturu tabulky můžete vidět zde:https://data.stackexchange.com/stackoverflow/query /nové , který pochází z dotazu na meta:Jak se ukládá SO revize?
Jako revizní systém funguje SO dobře a funkce markdown/revision je pravděpodobně dobrým příkladem, který si můžete vybrat.