Bagaimana seharusnya penghapusan ditangani dalam database?

Saya ingin menerapkan fitur "hapus" dalam aplikasi web sehingga pengguna dapat berubah pikiran dan memulihkan catatan yang dihapus. Pikiran tentang bagaimana menerapkan ini? Beberapa opsi yang saya pertimbangkan sebenarnya menghapus catatan yang dimaksud dan menyimpan perubahan dalam tabel audit terpisah, atau tidak menghapus catatan dan menggunakan kolom "dihapus" boolean untuk menandainya sebagai dihapus. Solusi terakhir akan membutuhkan logika aplikasi tambahan untuk mengabaikan catatan "dihapus" dalam keadaan normal, tetapi akan membuatnya lebih mudah untuk mengimplementasikan memulihkan catatan di sisi aplikasi.

Ya, saya pasti akan memilih opsi kedua, tetapi saya akan menambahkan satu bidang lagi sebagai bidang tanggal.

Jadi, Anda menambahkan:

delete       boolean
delete_date  timestamp

Ini akan memberi Anda waktu untuk tindakan yang tidak terhapuskan.

Jika waktu kurang dari satu jam, seseorang dapat membatalkan penghapusan.

Untuk benar-benar menghapus entri yang dihapus, cukup buat prosedur tersimpan yang akan membersihkan setiap entri dengan penghapusan yang disetel ke true dan waktu lebih dari satu jam dan meletakkannya sebagai tab cron yang berjalan setiap 24 jam

Jam hanyalah sebuah contoh.

Dalam aplikasi kami, kami tidak benar - benar menghapus apa pun atas permintaan pengguna (klien kami berada di lingkungan yang diatur di mana menghapus sesuatu yang berpotensi menyebabkan masalah hukum).

Kami menyimpan versi lama dalam tabel audit terpisah (jadi untuk tabel some_table di mana juga merupakan tabel yang disebut some_table_audit) yang identik selain memiliki pengenal versi tambahan (stempel waktu jika DB Anda mendukung nilai waktu cukup granular, nomor versi bilangan bulat atau UUID yang merupakan kunci asing ke tabel audit umum, atau sebagainya), dan memperbarui tabel audit secara otomatis oleh pemicu (jadi kita tidak perlu membuat semua kode yang memperbarui catatan mengetahui persyaratan audit).

Cara ini:

• operasi penghapusan hanyalah penghapusan sederhana - tidak perlu menambahkan kode tambahan apa pun untuk itu (meskipun Anda mungkin ingin merekam siapa yang meminta baris apa yang akan dihapus, meskipun sebenarnya tidak dihapus)
• sisipan dan pembaruan juga sederhana
• Anda dapat menerapkan hapus atau kembalikan dengan hanya mengembalikan baris "normal" ke versi lama (pemicu audit akan menyala lagi sehingga tabel jejak audit juga akan mencerminkan perubahan ini)
• Anda dapat menawarkan kesempatan untuk meninjau atau kembali ke versi masa lalu tidak hanya membatalkan penghapusan yang terakhir
• Anda tidak perlu menambahkan "ditandai sebagai dihapus?" memeriksa setiap titik kode yang merujuk ke tabel yang dimaksud, atau logika "perbarui salinan audit" ke setiap titik kode yang menghapus / memperbarui baris (meskipun Anda harus memutuskan apa yang harus dilakukan dengan baris yang dihapus dalam tabel audit: kami memang memiliki dihapus / tidak ditandai untuk setiap versi di sana sehingga tidak ada lubang dalam riwayat jika catatan dihapus dan kemudian dihapus)
• menyimpan salinan audit dalam tabel terpisah berarti Anda dapat mempartisinya menjadi beberapa grup file dengan mudah.

Jika menggunakan cap waktu alih-alih (atau juga) nomor versi integer, Anda dapat menggunakan ini untuk menghapus salinan lama setelah jumlah waktu yang ditentukan jika diperlukan. Tetapi ruang disk relatif murah akhir-akhir ini, jadi kecuali kami memiliki alasan untuk menghapus data lama (yaitu peraturan perlindungan data yang mengatakan Anda harus menghapus data klien setelah X bulan / tahun) kami tidak akan melakukannya.

Jawaban ini sudah ada beberapa tahun dan beberapa hal penting yang dapat memengaruhi perencanaan semacam ini telah berubah sejak saat itu. Saya tidak akan membahas detail besar, tetapi dengan singkat untuk kepentingan orang-orang yang membaca ini hari ini:

• SQL Server 2016 memperkenalkan "tabel temporal versi sistem" yang melakukan banyak pekerjaan ini untuk Anda, dan lebih dari itu karena beberapa gula sintaksis yang bagus disediakan untuk membuat kueri historis lebih mudah dibangun & dipelihara, dan mereka mengoordinasikan sejumlah perubahan skema di antara tabel dasar dan sejarah. Mereka bukannya tanpa peringatan, tetapi mereka adalah alat yang ampuh untuk tujuan semacam ini. Fitur serupa juga tersedia di sistem DB lainnya.

• Perubahan pada undang-undang perlindungan data, khususnya pengenalan GDPR, dapat secara signifikan mengubah masalah kapan data harus dihapus dengan keras. Anda harus mempertimbangkan keseimbangan tidak menghapus data yang mungkin berguna (atau, memang, secara hukum diperlukan) untuk keperluan audit di kemudian hari terhadap keharusan menghormati hak-hak masyarakat (baik secara umum maupun yang secara khusus diatur dalam undang-undang yang relevan) ketika mempertimbangkan desain Anda. Ini bisa menjadi masalah dengan tabel temporal versi sistem karena Anda tidak dapat mengubah riwayat untuk membersihkan data pribadi tanpa skema perubahan jangka pendek untuk mematikan pelacakan riwayat saat Anda membuat perubahan.

Dengan kolom yang dihapus boolean, Anda akan mulai mengalami masalah jika tabel Anda mulai tumbuh dan menjadi sangat besar. Saya sarankan Anda memindahkan kolom yang dihapus seminggu sekali (lebih atau kurang tergantung pada spesifikasi Anda) ke tabel yang berbeda. Dengan begitu Anda memiliki meja aktif kecil yang bagus dan yang besar yang berisi semua catatan yang dikumpulkan dari waktu ke waktu.

Saya akan pergi dengan meja terpisah. Ruby on Rails memiliki acts_as_versionedplugin, yang pada dasarnya menyimpan satu baris ke tabel lain dengan postfix _versionsebelum memperbaruinya. Meskipun Anda tidak memerlukan perilaku yang tepat, itu juga harus berfungsi untuk kasus Anda (salin sebelum menghapus).

Seperti @Spredzy, saya juga merekomendasikan untuk menambahkan delete_datekolom agar dapat secara sistematis membersihkan catatan yang belum dipulihkan setelah X jam / hari / apa pun.

Solusi yang kami gunakan secara internal untuk masalah ini adalah memiliki kolom status dengan beberapa nilai kode keras untuk beberapa status objek tertentu: Dihapus, Aktif, Tidak Aktif, Terbuka, Tertutup, Diblokir - setiap status dengan beberapa makna yang digunakan dalam aplikasi. Dari sudut pandang db kami tidak menghapus objek, kami hanya mengubah status dan menyimpan histori untuk setiap perubahan dalam tabel objek.

Ketika Anda mengatakan bahwa "Solusi terakhir akan membutuhkan logika aplikasi tambahan untuk mengabaikan catatan 'dihapus'", solusi sederhana adalah memiliki tampilan yang menyaring mereka.

Mirip dengan apa yang disarankan Spredzy, kami menggunakan bidang stempel waktu untuk dihapus di semua aplikasi kami. Boolean berlebihan, karena cap waktu yang ditetapkan menunjukkan bahwa catatan telah dihapus. Dengan cara ini, PDO kami selalu menambah AND (deleted IS NULL OR deleted = 0)pernyataan pilih, kecuali model secara eksplisit meminta catatan yang dihapus dimasukkan.

Saat ini kami tidak mengumpulkan sampah kecuali pada tabel yang berisi gumpalan atau teks; ruang sepele jika catatan dinormalisasi dengan baik, dan pengindeksan deletedbidang membuat dampak terbatas pada kecepatan pilih.

Sebagai alternatif, Anda dapat menempatkan tanggung jawab pada pengguna (dan pengembang) dan pergi dengan urutan 'Apakah Anda yakin?', 'Apakah Anda yakin?' dan "Apakah Anda benar-benar yakin?" pertanyaan sebelum catatan dihapus. Agak licik tapi layak dipertimbangkan.

Saya terbiasa melihat baris tabel dengan kolom seperti 'DeletedDate' di dalamnya dan saya tidak menyukainya. Gagasan 'dihapus' adalah bahwa entri seharusnya tidak dibuat sejak awal. Secara praktis, mereka tidak dapat dihapus dari database tetapi saya tidak ingin mereka dengan data panas saya. Baris yang secara logis dihapus adalah, menurut definisi, data dingin kecuali seseorang secara spesifik ingin melihat data yang dihapus.

Selain itu, setiap permintaan yang ditulis harus secara khusus mengecualikannya dan indeks harus mempertimbangkannya juga.

Yang ingin saya lihat adalah perubahan pada tingkat arsitektur basis data dan tingkat aplikasi: buat skema yang disebut 'dihapus'. Setiap tabel yang ditentukan pengguna memiliki padanan yang identik dalam skema 'dihapus' dengan bidang tambahan yang menahan metadata - pengguna yang menghapusnya dan kapan. Kunci asing perlu dibuat.

Selanjutnya, hapus menjadi sisipan-hapus. Pertama, baris yang akan dihapus dimasukkan ke dalam skema mitra 'dihapus'. Baris yang dimaksud di tabel utama kemudian dapat dihapus. Namun, logika tambahan perlu ditambahkan di suatu tempat di sepanjang garis. Pelanggaran kunci asing dapat ditangani.

Kunci asing harus ditangani dengan benar. Ini adalah praktik yang buruk untuk menghapus baris secara logis tetapi yang primer / uniknya memiliki kolom di tabel lain yang merujuknya. Ini seharusnya tidak terjadi. Pekerjaan biasa dapat menghapus baris janda (baris yang kunci utamanya tidak memiliki referensi di tabel lain meskipun ada kunci asing. Namun, ini adalah logika bisnis.

Manfaat keseluruhan adalah pengurangan metadata dalam tabel dan peningkatan kinerja yang dimilikinya. Kolom 'deleteDate' mengatakan bahwa baris ini seharusnya tidak benar-benar ada di sini, tetapi demi kenyamanan, kita membiarkannya di sana dan membiarkan query SQL menanganinya. Jika salinan baris yang dihapus disimpan dalam skema 'dihapus', maka tabel utama dengan data panas memiliki persentase lebih tinggi dari data panas (dengan asumsi itu diarsipkan secara tepat waktu) dan lebih sedikit kolom metadata yang tidak perlu. Indeks & kueri tidak perlu lagi mempertimbangkan bidang ini. Semakin pendek ukuran baris, semakin banyak baris yang bisa dipasang ke halaman, semakin cepat SQL Server dapat bekerja.

Kerugian utama adalah ukuran operasi. Sekarang ada dua operasi bukan satu serta logika tambahan dan penanganan kesalahan. Ini dapat menyebabkan lebih banyak penguncian daripada memperbarui satu kolom jika tidak akan mengambil. Transaksi memegang kunci di atas meja lebih lama dan ada dua meja yang terlibat. Menghapus data produksi, setidaknya dalam pengalaman saya, adalah sesuatu yang jarang dilakukan. Meski begitu, di salah satu tabel utama, 7,5% dari hampir 100 juta entri memiliki entri di kolom 'DeletedDate'.

Sebagai jawaban untuk pertanyaan, aplikasi harus menyadari 'membatalkan penghapusan. Ini hanya perlu melakukan hal yang sama dalam urutan terbalik: masukkan baris dari skema 'dihapus' ke tabel utama dan kemudian hapus baris dari skema 'dihapus. Lagi-lagi beberapa logika & penanganan kesalahan tambahan diperlukan untuk memastikan untuk menghindari kesalahan, masalah dengan kunci asing dan sejenisnya.