Korzystanie z sekwencyjnego id byłoby prostsze, ponieważ prawdopodobnie (?) jest kluczem podstawowym, a zatem indeksowanym i szybszym w dostępie. Biorąc pod uwagę, że masz user_id , możesz szybko potwierdzić ostatnie i wcześniejsze zmiany.
Korzystanie z timestamp ma również zastosowanie, ale prawdopodobnie będzie to dłuższy wpis i nie wiemy, czy w ogóle jest indeksowany, plus ryzyko kolizji. Słusznie zauważyłeś, że zegary systemowe mogą się zmieniać... Podczas gdy sekwencyjny id nie może.
Po otrzymaniu aktualizacji:
Ponieważ trudno jest zobaczyć, jakie są twoje dokładne wymagania, uwzględniłem to jako dowód tego, czego konkretny projekt wymagał dla ponad 200 000 złożonych dokumentów i milionów poprawek.
Z własnego doświadczenia (budowa w pełni audytowalnego systemu doc/profiling) dla wewnętrznego zespołu ponad 60 pełnoetatowych badaczy. Skończyło się na użyciu zarówno id i wiele innych pól (w tym timestamp ), aby zapewnić śledzenie audytu i pełną wersję.
Zbudowany przez nas system ma ponad 200 pól dla każdego profilu, a zatem wersjonowanie dokumentu było znacznie bardziej złożone niż przechowywanie bloku zmienionego tekstu/treści dla każdego z nich; Jednak każdy profil można edytować, zatwierdzać, odrzucać, cofać, publikować, a nawet eksportować jako plik PDF lub inny format jako JEDEN dokument.
To, co w końcu zrobiliśmy (po wielu strategiach/planowaniu) to przechowywanie kolejnych wersji profilu, ale były one zakodowane głównie na id pole .
Stemple czasowe
Znaczniki czasu zostały również przechwycone jako wtórna kontrola, a my upewniliśmy się, że zegary systemowe są dokładne (w grupie serwerów) za pomocą skryptów crona, które regularnie sprawdzają wyrównanie czasowe i poprawiają je w razie potrzeby. Użyliśmy również Ntpd aby zapobiec dryfowi zegara.
Inne przechwycone dane
Inne dane przechwycone dla każdej edycji również obejmowały (ale nie ograniczały się do):
User_id
User_group
Action
Approval_id
Były też inne tabele, które spełniały wymagania wewnętrzne (m.in. automatycznie generowane adnotacje do dokumentów) - ponieważ część edycji profilu odbywała się na podstawie danych z botów (zbudowanych przy użyciu NER/uczenia maszynowego/AI), ale za zgodą jednego z zespół przed opublikowaniem zmian/aktualizacji.
Prowadzony był również dziennik akcji wszystkich akcji użytkownika, tak aby w przypadku audytu można było przyjrzeć się akcji pojedynczego użytkownika - nawet jeśli nie miał uprawnień do wykonania takiej akcji, to i tak było to rejestrowane .
Jeśli chodzi o migrację, nie uważam tego za duży problem, ponieważ można łatwo zachować sekwencje id podczas przenoszenia/zrzucania/przesyłania danych. Być może jedynym problemem jest to, czy musisz scalić zestawy danych. W takim przypadku zawsze możesz napisać skrypt migracji - więc z osobistej perspektywy uważam, że ta wada nieco się zmniejszyła.
Warto przyjrzeć się strukturom tabeli Stack Overflow dla eksploratora danych (co jest dość wyrafinowane). Możesz zobaczyć strukturę tabeli tutaj:https://data.stackexchange.com/stackoverflow/query /nowy , który pochodzi z pytania na temat meta:Jak przechowuje SO zmiany?
Jako system poprawek SO działa dobrze, a funkcja przecen/weryfikacji jest prawdopodobnie dobrym przykładem do przejrzenia.
