manajemen baris sejarah dalam database

Pertanyaan pertama seharusnya:apa yang akan Anda lakukan dengan data itu? Jika Anda tidak memiliki persyaratan bisnis yang jelas, jangan lakukan.

Saya melakukan hal serupa dan setelah 3 tahun berjalan ada sekitar 20% "data yang valid" dan sisanya adalah "versi sebelumnya". Dan itu adalah 10 juta + 40 juta catatan. Dalam tiga tahun terakhir kami memiliki 2 (dua) permintaan untuk menyelidiki riwayat perubahan dan kedua kali permintaan itu konyol - kami mencatat cap waktu perubahan catatan dan kami diminta untuk memeriksa apakah orang bekerja lembur (setelah jam 5 sore).

Sekarang, kita terjebak dengan database besar yang berisi 80% data yang tidak dibutuhkan siapa pun.

EDIT:

Karena Anda meminta solusi yang mungkin, saya akan menjelaskan apa yang kami lakukan. Ini sedikit berbeda dari solusi yang Anda pertimbangkan.

1. Semua tabel memiliki kunci primer pengganti.
2. Semua kunci utama dihasilkan dari urutan tunggal. Ini berfungsi dengan baik karena Oracle dapat menghasilkan dan menyimpan nomor cache, jadi tidak ada masalah kinerja di sini. Kami menggunakan ORM dan kami ingin setiap objek dalam memori (dan catatan yang sesuai dalam database) memiliki pengenal unik
3. Kami menggunakan ORM dan memetakan informasi antara tabel database dan kelas dalam bentuk atribut.

Kami mencatat semua perubahan dalam tabel arsip tunggal dengan kolom berikut:

• id (kunci utama pengganti)
• cap waktu
• tabel asli
• id rekaman asli
• nomor pengguna
• jenis transaksi (masukkan, perbarui, hapus)
• merekam data sebagai bidang varchar2
  • ini adalah data aktual dalam bentuk pasangan fieldname/nilai.

Hal ini bekerja dengan cara ini:

• ORM memiliki perintah insert/update dan delete.
• kami membuat satu kelas dasar untuk semua objek bisnis kami yang menggantikan perintah insert/update dan delete
  • perintah insert/update/delete membuat string dalam bentuk pasangan fieldname/nilai menggunakan refleksi. Kode mencari informasi pemetaan dan membaca nama bidang, nilai terkait, dan jenis bidang. Kemudian kami membuat sesuatu yang mirip dengan JSON (kami menambahkan beberapa modifikasi). Saat string yang mewakili status objek saat ini dibuat, string tersebut dimasukkan ke dalam tabel arsip.
• ketika objek baru atau yang diperbarui disimpan ke tabel database, itu disimpan ke tabel targetnya dan pada saat yang sama kita memasukkan satu record dengan nilai saat ini ke dalam tabel arsip.
• ketika objek dihapus, kami menghapusnya dari tabel targetnya dan pada saat yang sama kami memasukkan satu record dalam tabel arsip yang memiliki tipe transaksi ="DELETE"

Pro:

• kami tidak memiliki tabel arsip untuk setiap tabel dalam database. Kami juga tidak perlu khawatir tentang memperbarui tabel arsip saat skema berubah.
• arsip lengkap dipisahkan dari "data saat ini", jadi arsip tidak memaksakan hit kinerja apa pun pada basis data. Kami meletakkannya di tablespace terpisah pada disk terpisah dan berfungsi dengan baik.
• kami membuat 2 formulir untuk melihat arsip:
  • penampil umum yang dapat membuat daftar tabel arsip menurut filter pada tabel arsip. Filter data yang dapat dimasukkan pengguna pada formulir (rentang waktu, pengguna, ...). Kami menampilkan setiap record dalam bentuk fieldname/value dan setiap perubahan diberi kode warna. Pengguna dapat melihat semua versi untuk setiap catatan dan mereka dapat melihat siapa dan kapan membuat perubahan.
  • penampil faktur - yang ini rumit, tetapi kami membuat formulir yang menunjukkan faktur sangat mirip dengan formulir entri faktur asli, tetapi dengan beberapa tombol tambahan yang dapat menunjukkan generasi yang berbeda. Butuh banyak usaha untuk membuat formulir ini. Formulir digunakan beberapa kali dan kemudian dilupakan karena tidak diperlukan dalam alur kerja saat ini.
• kode untuk membuat catatan arsip terletak di kelas C# tunggal. Tidak perlu trigger di setiap tabel dalam database.
• kinerjanya sangat bagus. Pada waktu puncak, sistem digunakan oleh sekitar 700-800 pengguna. Ini adalah aplikasi ASP.Net. Baik ASP.Net dan Oracle berjalan pada satu XEON ganda dengan RAM 8Gb.

Kekurangan:

• format arsip tabel tunggal lebih sulit dibaca daripada solusi di mana ada satu tabel arsip untuk setiap tabel data.
• mencari bidang non-id di tabel arsip sulit - kita hanya dapat menggunakan LIKE operator pada string.

Jadi, sekali lagi, periksa persyaratan di arsip . Ini bukan tugas yang sepele, tetapi perolehan dan penggunaan bisa jadi minimal.