Menggunakan id yang berurutan akan lebih sederhana karena mungkin(?) kunci utama dan dengan demikian diindeks dan lebih cepat untuk diakses. Mengingat Anda memiliki user_id , Anda dapat dengan cepat menegaskan pengeditan terakhir dan sebelumnya.
Menggunakan timestamp juga berlaku, tetapi kemungkinan entrinya lebih panjang, dan kami tidak tahu apakah itu diindeks sama sekali, ditambah potensi tabrakan. Anda dengan tepat menunjukkan bahwa jam sistem dapat berubah... Sedangkan id sequential berurutan tidak bisa.
Mengingat pembaruan Anda:
Karena sulit untuk melihat apa persyaratan sebenarnya Anda, saya telah menyertakan ini sebagai bukti tentang apa yang dibutuhkan proyek tertentu untuk 200 ribu+ dokumen kompleks dan jutaan revisi.
Dari pengalaman saya sendiri (membangun sistem dokumen/profil yang sepenuhnya dapat diaudit) untuk tim internal yang terdiri lebih dari 60 peneliti penuh waktu. Kami akhirnya menggunakan id dan sejumlah bidang lainnya (termasuk timestamp ) untuk menyediakan pelacakan audit dan pembuatan versi lengkap.
Sistem yang kami bangun memiliki lebih dari 200 bidang untuk setiap profil dan dengan demikian membuat versi dokumen jauh lebih kompleks daripada hanya menyimpan satu blok teks/konten yang diubah untuk masing-masing profil; Namun, setiap profil dapat, diedit, disetujui, ditolak, dibatalkan, diterbitkan, dan bahkan diekspor sebagai PDF atau format lain sebagai SATU dokumen.
Apa yang akhirnya kami lakukan (setelah banyak strategi/perencanaan) adalah menyimpan versi profil yang berurutan, tetapi mereka dikunci terutama pada id bidang .
Stempel waktu
Stempel waktu juga ditangkap sebagai pemeriksaan sekunder dan kami memastikan untuk menjaga keakuratan jam sistem (di antara sekelompok server) melalui penggunaan skrip cron yang memeriksa penyelarasan waktu secara teratur dan mengoreksinya jika perlu. Kami juga menggunakan Ntpd untuk mencegah pergeseran jam.
Data lain yang diambil
Data lain yang diambil untuk setiap pengeditan juga disertakan (namun tidak terbatas pada):
User_id
User_group
Action
Approval_id
Ada juga tabel lain yang memenuhi persyaratan internal (termasuk anotasi yang dibuat secara otomatis untuk dokumen) - karena beberapa pengeditan profil dilakukan menggunakan data dari bot (dibangun menggunakan NER/pembelajaran mesin/AI), tetapi dengan persetujuan yang diperlukan oleh salah satu tim sebelum suntingan/pembaruan dapat dipublikasikan.
Log tindakan juga disimpan dari semua tindakan pengguna, sehingga dalam hal audit, seseorang dapat melihat tindakan pengguna individu - bahkan ketika mereka tidak memiliki izin untuk melakukan tindakan seperti itu, itu masih dicatat .
Berkenaan dengan migrasi, saya tidak melihatnya sebagai masalah besar, karena Anda dapat dengan mudah mempertahankan urutan id dalam memindahkan/membuang/mentransfer data. Mungkin satu-satunya masalah adalah jika Anda perlu menggabungkan kumpulan data. Anda selalu dapat menulis skrip migrasi dalam acara itu - jadi dari sudut pandang pribadi saya menganggap kerugian itu agak berkurang.
Mungkin ada baiknya melihat struktur tabel Stack Overflow untuk penjelajah data di sana (yang cukup canggih). Anda dapat melihat struktur tabel di sini:https://data.stackexchange.com/stackoverflow/query /baru , yang berasal dari pertanyaan di meta:Bagaimana cara SO menyimpan revisi?
Sebagai sistem revisi, SO bekerja dengan baik dan fungsionalitas penurunan harga/revisi mungkin merupakan contoh yang baik untuk dipilih.
