Използване на последователния id би било по-просто, тъй като вероятно (?) е първичен ключ и по този начин индексиран и по-бърз за достъп. Като се има предвид, че имате user_id , можете бързо да потвърдите последните и предишни редакции.
Използване на timestamp също е приложимо, но е вероятно да е по-дълъг запис и не знаем дали изобщо е индексиран, плюс потенциала за сблъсъци. Правилно отбелязвате, че системните часовници могат да се променят... Докато последователният id не може.
Предвид вашата актуализация:
Тъй като е трудно да се види какви са вашите точни изисквания, включих това като доказателство за това какво изисква конкретен проект за 200K+ сложни документа и милиони ревизии.
От моя собствен опит (изграждане на напълно подлежаща на одит система за документи/профилиране) за вътрешен екип от повече от 60 изследователи на пълен работен ден. В крайна сметка използвахме и id и редица други полета (включително timestamp ), за да осигури проследяване на одит и пълна версия.
Системата, която изградихме, има повече от 200 полета за всеки профил и по този начин версията на документ беше много по-сложна от простото съхраняване на блок с променен текст/съдържание за всеки един; Все пак всеки профил може да бъде, редактиран, одобрен, отхвърлен, върнат, публикуван и дори експортиран като PDF или друг формат като ЕДИН документ.
Това, което в крайна сметка направихме (след много стратегии/планиране), беше да съхраним последователни версии на профила, но те бяха ключови основно на id полето .
Клейма за време
Времевите клейма също бяха заснети като вторична проверка и ние се уверихме да поддържаме системните часовници точни (сред клъстер от сървъри) чрез използването на cron скриптове, които проверяваха редовно подравняването на времето и ги коригираха, когато е необходимо. Използвахме и Ntpd за предотвратяване на отклонение на часовника.
Други заснети данни
Други данни, заснети за всяка редакция, също включват (но не само):
User_id
User_group
Action
Approval_id
Имаше и други таблици, които отговаряха на вътрешни изисквания (включително автоматично генерирани анотации за документите) - тъй като част от редактирането на профили беше извършено с помощта на данни от ботове (създадени с помощта на NER/машинно обучение/AI), но с изискване на одобрение от един от екипа, преди редакциите/актуализациите да могат да бъдат публикувани.
Съхранява се и регистър на действията за всички действия на потребителя, така че в случай на одит да може да се видят действията на отделен потребител - дори когато не са имали разрешенията да извършат такова действие, то пак се регистрира .
По отношение на миграцията не го виждам като голям проблем, тъй като можете лесно да запазите последователностите на id при преместване/изхвърляне/прехвърляне на данни. Може би единственият проблем е дали трябва да обедините набори от данни. Винаги можете да напишете скрипт за мигриране в този случай - така че от лична гледна точка смятам, че този недостатък е донякъде намален.
Може би си струва да разгледате структурите на таблицата за препълване на стека за там изследовател на данни (който е сравнително сложен). Можете да видите структурата на таблицата тук:https://data.stackexchange.com/stackoverflow/query /ново , което идва от въпрос на meta:Как SO съхранява ревизии?
Като система за преразглеждане, SO работи добре и функционалността за маркиране/преразглеждане вероятно е добър пример за избор.
