De opeenvolgende id gebruiken zou eenvoudiger zijn omdat het waarschijnlijk (?) een primaire sleutel is en dus geïndexeerd en sneller toegankelijk is. Aangezien u user_id . heeft , kunt u snel de laatste en eerdere bewerkingen bevestigen.
De timestamp gebruiken is ook van toepassing, maar het is waarschijnlijk een langere invoer en we weten niet of het überhaupt is geïndexeerd, plus het potentieel voor botsingen. U wijst er terecht op dat systeemklokken kunnen veranderen... Terwijl sequentiële id 's kan niet.
Gezien je update:
Omdat het moeilijk is om te zien wat uw exacte vereisten zijn, heb ik dit toegevoegd als bewijs van wat een bepaald project vereiste voor meer dan 200K complexe documenten en miljoenen revisies.
Vanuit mijn eigen ervaring (het bouwen van een volledig controleerbaar doc/profileringssysteem) voor een intern team van meer dan 60 fulltime onderzoekers. We hebben uiteindelijk zowel een id en een aantal andere velden (inclusief timestamp ) om audit-trailing en volledige versiebeheer te bieden.
Het systeem dat we hebben gebouwd heeft meer dan 200 velden voor elk profiel en dus was het versiebeheer van een document veel complexer dan alleen het opslaan van een blok gewijzigde tekst/inhoud voor elk profiel; Toch kan elk profiel worden bewerkt, goedgekeurd, afgewezen, teruggedraaid, gepubliceerd en zelfs geëxporteerd als een PDF of een ander formaat als EEN document.
Wat we uiteindelijk deden (na veel strategie/planning) was om opeenvolgende versies van het profiel op te slaan, maar ze waren in de eerste plaats ingetoetst voornamelijk op een id veld .
Tijdstempels
Tijdstempels werden ook vastgelegd als secundaire controle en we zorgden ervoor dat de systeemklokken nauwkeurig werden gehouden (tussen een cluster van servers) door het gebruik van cron-scripts die de tijdafstemming regelmatig controleerden en waar nodig corrigeerden. We gebruikten ook Ntpd om klokslag te voorkomen.
Andere vastgelegde gegevens
Andere gegevens die voor elke bewerking zijn vastgelegd, omvatten ook (maar niet beperkt tot):
User_id
User_group
Action
Approval_id
Er waren ook andere tabellen die voldeden aan de interne vereisten (inclusief automatisch gegenereerde annotaties voor de documenten) - aangezien een deel van de profielbewerking werd gedaan met behulp van gegevens van bots (gebouwd met NER/machine learning/AI), maar waarvoor goedkeuring vereist was door een van het team voordat bewerkingen/updates konden worden gepubliceerd.
Er werd ook een actielogboek bijgehouden van alle gebruikersacties, zodat men bij een audit de acties van een individuele gebruiker kon bekijken - zelfs als deze niet de rechten had om een dergelijke actie uit te voeren, werd deze toch gelogd .
Met betrekking tot migratie zie ik het niet als een groot probleem, omdat je de id-reeksen gemakkelijk kunt behouden bij het verplaatsen / dumpen / overbrengen van gegevens. Misschien is het enige probleem dat u gegevenssets moet samenvoegen. Je zou in dat geval altijd een migratiescript kunnen schrijven - dus persoonlijk beschouw ik dat nadeel enigszins verminderd.
Het is misschien de moeite waard om naar de Stack Overflow-tabelstructuren te kijken voor hun gegevensverkenner (die redelijk geavanceerd is). Je kunt de tabelstructuur hier zien:https://data.stackexchange.com/stackoverflow/query /nieuw , die voortkomt uit een vraag over meta:Hoe slaat SO op revisies?
Als revisiesysteem werkt SO goed en de markdown-/revisiefunctionaliteit is waarschijnlijk een goed voorbeeld om over te nemen.