Cara memiliki riwayat perubahan entri basis data

Apa cara untuk memungkinkan versi entri basis data (data)?

Pikirkan kemampuan sistem manajemen konten untuk mengembalikan kembali perubahan artikel.

Apa pro / kontra mereka?

Pada dasarnya ada dua pendekatan: tabel audit, dengan semua nilai sebelumnya disimpan di dalamnya, atau sertakan tanggal mulai / berakhir sebagai bagian dari tabel, dan semua pembaruan membuat catatan baru sambil menutup yang lama.

Pembaruan: SQL SERVER 2016 mendukung ini sebagai pola desain / jenis tabel - https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-2017

Satu ide adalah menggunakan "Masukkan-Hanya Basis Data". Ide dasarnya adalah bahwa Anda tidak pernah menghapus atau memperbarui data pada satu baris .

Setiap tabel yang harus dilacak akan memiliki dua datetimekolom fromdan to. Mereka mulai dengan nilai NULLdi masing-masing (awal waktu hingga akhir waktu). Ketika Anda perlu "mengubah" baris Anda menambahkan baris baru, dan pada saat yang sama Anda memperbarui todi baris sebelumnya ke Nowdan fromdi baris yang Anda tambahkan Now.

Untuk info lebih rinci, lihat:

• Gagasan tentang desain basis data untuk menangkap jejak audit
• Desain terbaik untuk tabel database changelog / audit?

Teknik ini disebut AuditTrailuntuk mengelola data lawas, dan itu agak menyimpan sejarah perubahan.

Sepertinya pertanyaan seperti ini sudah diposting:

• /programming//q/1051449/1437962
• /programming//q/201527/1437962

Saya pikir Anda dapat menggunakan pemicu untuk setiap tabel dan mempertahankan data dalam _history (atau Anda dapat memberikan nama apa pun) dan pada setiap sisipan, perbarui, hapus pada tabel utama akan memicu pemicu Anda dan Anda dapat menyimpan detailnya di tabel ini. Mekanisme pemicu juga tersedia dengan database SQLite jika Anda menggunakannya.

Mekanisme ini berguna untuk proyek-proyek besar juga. Dalam tabel ini Anda bisa mencatat informasi pengguna yang telah membuat perubahan bersama dengan cap waktu perubahan. Anda kemudian dapat mengembalikan tabel ke pencocokan cap waktu dengan kebutuhan Anda.

Setiap Database memiliki cara sendiri untuk menulis dan memicu kode. Jika Anda menggunakan SQLite, kunjungi SQLite.org untuk sintaksisnya. Untuk basis data lain, Anda dapat mengunjungi situs resminya.

Anda mungkin mengetahui mesin Sqlite db. Seluruh db disimpan dalam satu file. Api juga mendukung sistem file virtual sehingga pada dasarnya Anda dapat mengatur penyimpanan di mana saja dan dengan format apa pun, cukup menanggapi operasi baca dan tulis pada offset file tertentu. Kemungkinan aplikasi untuk ini bisa berupa enkripsi, kompresi, dan sebagainya. Bagian terbaiknya adalah layer container seharusnya tidak tahu apa-apa tentang basis data, format file sql atau sqlite, cukup patuhi callback xRead dan xWrite.

Salah satu idenya adalah menerapkan fitur mesin waktu. Jadi setiap operasi xWrite menyimpan setiap segmen yang akan ditimpa dalam "undo" history dan pengguna dapat memilih tanggal di masa lalu untuk melihat apa yang terkandung dalam db (mungkin mode read-only). Saya belum memiliki contoh kerja (ada diskusi tentang hal itu di milis sqlite), tetapi mungkin mesin lain menyediakan API VFS sehingga hal serupa mungkin terjadi. Dan begitu itu diterapkan, itu harus kompatibel dengan struktur database dari kompleksitas apa pun.

Metode yang kami gunakan untuk memvariasikan entri basis data adalah dengan menggunakan tabel audit. Tabel memiliki skema di sepanjang garis:

Seq      - Int      ' Unique identifier for this table
Event    - Char     ' Insert / Update / Delete
TblName  - Char     ' Table that had field value changed
FldName  - Char     ' Field that was changed
KeyValue - Char     ' delimited list of values for fields that make up the PK of table changed
UsrId    - Char     ' User who made the change
OldValue - Char     ' Old value (converted to character)
NewValue - Char     ' New value (converted to character)
AddTs    - DateTime ' When the change was made

Kami kemudian memiliki pemicu pada Sisipkan / Perbarui / Hapus tabel yang ingin kami lacak.

Pro:

• Semua data dalam satu tabel
• Dapat diatur untuk melacak semua bidang atau bidang tertentu dalam sebuah tabel
• Mudah menampilkan versi pada setiap bidang untuk tabel

Kekurangan:

• Memiliki semua informasi audit dalam satu tabel menghasilkan sejumlah besar catatan
• Banyak pemicu yang dibutuhkan

Saya sedang melakukan versi ini sekarang. untuk setiap catatan saya memiliki Tanggal yang Dimasukkan, Tanggal yang dimodifikasi dan dan bendera boolean Rekaman Aktif. Untuk penyisipan awal, tanggal yang Dimasukkan dan Dimodifikasi disetel ke Sekarang () (Contoh ini di Access) dan bendera catatan Aktif diatur ke true. kemudian jika saya mengubah catatan itu saya menyalin semuanya ke catatan baru, mengubah bidang yang diubah pengguna, saya meninggalkan tanggal Sisipkan sama dengan yang asli dan mengubah tanggal Dimodifikasi ke Sekarang (). Saya kemudian membalik bendera Rekaman Aktif dari catatan asli ke falsedan catatan baru ke true. Saya juga memiliki bidang untuk ModifiedRecordsParentID tempat saya menyimpan identitas catatan asli.

Kemudian Jika saya perlu melakukan query, saya hanya dapat mengembalikan record di mana ActiveRecord = truedan saya hanya akan mendapatkan informasi terbaru.

juga, jika Anda ingin menyimpan SEMUA perubahan pada DB dari waktu ke waktu, Anda mungkin ingin memeriksa pencatatan ( /programming/3394132/where-can-i-find-the-mysql-transaction-log )