Haruskah kita menghapus data dalam database?


40

Saya baru mengenal database dan mencoba memahami konsep dasar. Saya telah belajar cara menghapus data dalam database. Tetapi salah satu teman saya mengatakan kepada saya bahwa Anda seharusnya tidak pernah menghapus data dalam database. Sebaliknya, ketika itu tidak lagi diperlukan, lebih baik hanya menandainya atau menandai sebagai 'tidak digunakan'.

Benarkah? Jika demikian, bagaimana perusahaan besar seperti IBM menangani data mereka selama seratus tahun atau lebih?


2
Tolong jelaskan - apakah Anda bertanya apakah Anda harus mengeluarkan perintah hapus dalam SQL, atau Anda bertanya apakah mesin database yang mendasari benar-benar menghapus data yang ditandai sebagai dihapus?
GrandmasterB

4
@StartupCrazy: komentar itu tidak menjelaskan apa pun untuk saya.
Doc Brown

6
Siapa yang dimaksud dengan "kita"?
Dinamis

3
Saya sangat suka menjaga semuanya hampir secara obsesif. Tetapi saya tidak tahu dalam bisnis apa Anda ini, tetapi beberapa data yang secara hukum Anda harus simpan untuk beberapa waktu tertentu dan beberapa data Anda secara hukum harus dihapus setelah beberapa waktu tertentu.
Pieter B

6
Tergantung pada data apa itu. Dalam beberapa kasus, Anda harus menghapusnya karena alasan hukum.
CodesInChaos

Jawaban:


64

Seperti semua hal ini, jawabannya adalah "itu tergantung".

Jika pengguna cenderung menginginkan data kembali maka teman Anda benar - Anda tidak benar-benar menghapus cukup tandai catatan sebagai "dihapus". Dengan cara ini ketika pengguna berubah pikiran Anda dapat memulihkan data.

Namun, jika data yang dihapus lebih dari periode waktu tertentu (misalnya satu tahun), Anda mungkin memutuskan untuk benar-benar menghapusnya dari tabel langsung tetapi menyimpannya dalam tabel arsip atau bahkan hanya cadangan jika pengguna ingin kembali. Dengan cara ini Anda dapat menjaga jumlah data (hidup dan yang baru-baru ini dihapus) ke minimum.

Namun, jika datanya fana atau mudah dibuat ulang, Anda mungkin memutuskan untuk benar-benar menghapus data.

Ada satu kelas data yang harus Anda hapus - dan itu adalah data pribadi yang pengguna tidak ingin Anda pegang lagi. Mungkin ada undang-undang setempat (misalnya di UE) yang menjadikan ini persyaratan wajib (terima kasih Gavin )

Sama halnya mungkin ada aturan yang mengharuskan Anda untuk tidak menghapus data, jadi sebelum memutuskan apa pun periksa dengan otoritas regulasi apa pun yang perlu Anda lakukan untuk mematuhi hukum.


8
Beberapa area aplikasi (akunting, perangkat medis) mungkin mensyaratkan data tidak dihapus karena persyaratan audit.
Paul

3
Dalam keadaan tertentu Anda HARUS menghapus data, contohnya adalah apa pun yang berkaitan dengan informasi pribadi pengguna. Hukum Uni Eropa (dan mungkin yang lain) menyatakan bahwa pengguna harus memiliki hak untuk meminta agar data mereka dihapus. Dalam kasus seperti ini, data ini harus dihapus, dan tidak ditandai hanya karena tidak lagi aktif. Yang terakhir akan menjadi pelanggaran hukum privasi.
Gavin Coates

apakah membebaskan beberapa ruang di basis data meningkatkan kinerjanya?
viveksinghggits

17

Ini sebenarnya masalah besar bagi banyak perusahaan. Tidak ada cara untuk secara jelas menentukan data apa yang sebenarnya digunakan, jadi ia hanya berada di database. Penghapusan dan pengarsipan data harus menjadi bagian dari setiap desain sistem besar, tetapi jarang terjadi. Sebagian besar perusahaan hanya hidup dengan itu, membeli disk yang lebih besar dan mengutak-atik permintaan dan indeks mereka untuk mempertahankan kinerja, sampai mereka mengubah sistem dan kemudian mereka melalui sejumlah besar upaya untuk mengidentifikasi data saat ini dan kemudian hanya memindahkan catatan tersebut ke sistem baru mereka.

Ya, Anda harus menghapus data dari basis data Anda, tetapi seringkali tidak mudah untuk mengatakan apa dan kapan.


1
"Tidak ada cara untuk menentukan data apa yang sebenarnya digunakan" - saya tidak akan setuju. Bidang bit "IsDeleted" pada setiap tabel adalah cara yang cukup bersih untuk mengidentifikasi catatan yang tidak lagi relevan. Sebagian besar pertanyaan yang diajukan, seperti cara menghapus penghapusan, juga ada dalam skema penghapusan fisik, dan jawabannya tergantung pada model data dan apakah Anda lebih menghargai ukuran penyimpanan atau kinerja.
KeithS

Itulah yang saya katakan, sistem perlu dirancang dengan semacam indikator kedaluwarsa. Dengan tidak adanya indikator-indikator ini (yang merupakan kasus dengan banyak perusahaan), tidak ada cara untuk mengidentifikasi catatan mana yang dapat dihapus dengan aman.
TMN

12

Sudah ada banyak jawaban bagus untuk ini yang cukup banyak bermuara pada "Tergantung pada keadaan", dan saya tidak dapat menambahkan apa pun untuk itu.

Satu hal yang belum disebutkan, yang saya pikir perlu disebutkan, adalah bahwa Anda tidak boleh menggunakan kembali kunci primer yang dihasilkan oleh urutan atau sistem AUTO_INCREMENT.

Ketika Anda menghapus item yang telah diberikan kunci utama oleh sistem seperti itu, akan ada celah di kolom kunci utama, ditinggalkan oleh data yang dihapus. Ada godaan besar untuk menetapkan kembali kesenjangan tersebut ke item baru saat mereka ditambahkan, atau lebih buruk lagi, untuk mengocok data yang ada untuk memberikannya ID baru untuk menghilangkan kesenjangan, tetapi melakukan hal itu akan menimbulkan masalah yang Anda inginkan. tidak pernah harus berurusan dengan jika Anda meninggalkan kunci sendirian.

Katakanlah Anda menyimpan basis data printer untuk mengelola pemesanan ulang bahan habis pakai. Printer 13, sebuah printer laser tua, rusak melebihi perbaikan ekonomi sehingga Anda membuangnya. Sementara itu, untuk alasan yang tidak terkait, seseorang memesan printer termal baru untuk melakukan pencetakan barcode di gudang, dan printer itu tiba sebelum penggantian untuk printer 13. Administrator mencatat printer baru itu ke dalam database dan, karena 13 sekarang bebas dan Anda mendaur ulang ID, printer termal baru akan dialokasikan 13 sebagai ID-nya.

Sekarang seseorang memberi tahu Anda bahwa printer 13 hampir kehabisan tinta. Anda ingat bahwa printer 13 adalah printer laser sehingga Anda tidak perlu repot mencarinya di basis data, dan Anda memesan kartrid toner. Hanya Anda yang benar-benar perlu memesan paket tinta termal karena printer 13 bukan printer laser lagi. Ketika kartrid toner tiba, Anda tidak dapat menggunakannya karena ini adalah isi ulang tinta yang salah untuk printer, Anda tidak dapat mencetak lagi kode batang dan Anda tidak dapat mengirimkan pesanan yang menunggu untuk dikirim.

Lebih buruk lagi, apa yang terjadi jika Anda menghapus printer 13 dan mengacak semua printer yang datang untuk mengisi celah? Printer 14 (beberapa dot matrix tua jompo) menjadi printer 13, printer 15 menjadi printer 14 dan seterusnya.

Semua printer memiliki label pada mereka sehingga mereka dapat direferensikan silang dengan database, tetapi sekarang semua label sudah ketinggalan zaman. Anda harus berputar, mencari setiap printer dalam bisnis (yang bisa mencapai ratusan!) Dan memberi label baru. Itu bukan penggunaan waktu yang efektif. Dan ini juga merupakan proses yang rawan kesalahan, dan apa yang terjadi jika tidak pernah dilakukan? Seseorang memanggil untuk mengatakan printer 14 telah rusak dan perlu segera diperbaiki, sehingga Anda mencarinya dan menemukan bahwa printer 14 adalah printer inkjet di Penerimaan. Hanya karena Anda telah mengocok ID di sekitar, itu sebenarnya printer dot matrix yang perlu diperbaiki segera. Orang yang memanggil masalah dibiarkan menggantung, sementara resepsionis memiliki orang dukungan teknis yang dia tidak pernah panggil untuk memperbaiki printer yang tidak rusak.

Anda harus menganggap ID yang ditetapkan oleh sistem kenaikan otomatis sebagai permanen, tidak dapat diubah dan tidak dapat digunakan kembali, bahkan jika hal yang merujuk pada ID tidak ada lagi. Beberapa orang mengklaim bahwa mereka tidak ingin khawatir tentang kehabisan ID, tetapi bahkan dengan sistem 32 bit dan ID yang ditandatangani, masih ada sekitar 2 miliar ID yang tersedia. Jika Anda dapat membuat kolom ID tidak ditandatangani maka ini berlipat ganda menjadi 4 miliar, dan pada sistem 64 bit jumlah ID yang tersedia secara harfiah lebih besar dari jumlah bintang di langit. Anda tidak akan kehabisan ID.


3
Dalam kebanyakan kasus Anda tidak harus memikirkan nomor yang dihasilkan secara otomatis sama sekali, mereka tidak ada artinya dan tidak boleh diekspos kepada pengguna. Anda seharusnya tidak pernah mendapatkan pesan yang mengatakan tinta printer 13 rendah, mungkin "printer dalam suite 13", tetapi bukan nomor yang dihasilkan secara otomatis.
jmoreno

Benar, tetapi contoh di atas persis seperti itu, contoh untuk mengilustrasikan apa yang bisa salah jika Anda dipusingkan dengan kunci yang dihasilkan secara otomatis. Pada kenyataannya itu lebih berkaitan dengan integritas referensial.
GordonM

Ini hanya masalah RI jika Anda tidak memiliki batasan kunci asing dan sebaliknya memiliki kunci asing psuedo. Dalam hal ini Anda mungkin memiliki masalah yang lebih besar.
jmoreno

Anda akan terkejut betapa banyak database mysql yang masih saya temui persis seperti itu. Banyak pengembang tampaknya tidak menyukai innodb dan bahkan mereka yang tidak menggunakan semua fasilitasnya.
GordonM

4

Sudah banyak jawaban bagus di sini. Saya hanya ingin menambahkan satu situasi yang belum ada yang disebutkan:

Data sensitif . Jika pengguna menghapusnya, lebih baik Anda menghapusnya!

Satu situasi yang sangat umum yang muncul di pikiran adalah perubahan / reset kata sandi. Anda tidak ingin menyimpan kata sandi lama (meskipun kata sandi itu hash, asin, dll.) Di basis data Anda. Pengguna mungkin menggunakan kata sandi lama (dan buruk) di situs lain.

Juga, ketika datang ke undang-undang tentang berapa lama Anda diizinkan untuk menyimpan jenis data tertentu maka tentu saja penghapusan lunak tidak akan dilakukan. Anda harus benar-benar menghapusnya.

Jadi saya akan bertanya pada diri sendiri: apakah pengguna (atau orang lain, pemerintah misalnya) akan marah jika saya membuat mereka percaya data telah dihapus, tetapi sebenarnya saya masih mendapatkannya dan dapat memulihkannya kapan saja?


Menarik. Apakah perusahaan besar benar-benar menerapkan ini?
fuddin

2
Ini adalah poin yang bagus, tetapi untuk contoh riwayat kata sandi Anda - Anda sering ingin menyimpan kata sandi lama sehingga Anda dapat memastikan mereka bukan duplikat dalam 12 tahun terakhir atau apa pun. Jangan salah paham - Saya tidak suka kebijakan ini, tetapi saya telah menerapkannya, dan sepertinya cukup umum di aplikasi enterprise-y.
Mike Partridge

2
Hanya untuk menjadi sombong, Anda tidak boleh menyimpan kata sandi di mana pun. Anda menyimpan hasil terenkripsi (satu arah). Jika seseorang lupa kata sandi mereka, Anda membuat yang baru untuk mereka. Seharusnya TIDAK ADA CARA "memulihkan" kata sandi, karena jika Anda bisa melakukannya, orang lain juga bisa melakukannya.
TMN

1
Nomor kartu kredit. Seharusnya tidak pernah disimpan. Sebenarnya HARUS tidak pernah disimpan. Jika seorang pelanggan cukup bodoh untuk mengirimi saya nomor kartu kredit mereka dalam email, saya punya masalah nyata. Pasti ada cara untuk menyingkirkannya.
gnasher729

GDPR UE mengirimkan salam mereka.
displayname

3

Saya biasanya tidak menghapus data pengguna di database saya. Saya menandai mereka untuk disembunyikan. Seringkali seorang pengguna menghapus sesuatu secara tidak sengaja dan perlu diganti dengan mudah. Ini juga membantu mempertahankan integritas referensial untuk data terkait. Ini berfungsi untuk database ukuran kecil hingga sedang. Dalam sistem di mana kinerja sangat dipengaruhi oleh keputusan ini ditangani dengan cara khusus, misalnya tabel arsip, cadangan otomatis, dll.

Kami membuang data backend seperlunya, misalnya data sesi situs web kedaluwarsa dan informasi log lama. Tidak ada gunanya menjaga mereka selamanya.

Namun, seperti biasa, jawaban pastinya sangat tergantung pada situasi spesifik.


1

Saya telah mengerjakan aplikasi Valuta Asing selama beberapa tahun di mana ini muncul. Data yang dikumpulkan aplikasi selama bertahun-tahun berdampak pada kinerja (katakanlah eksponensial).

Setelah kami melakukan apa yang kami bisa dalam hal kode, kami mengusulkan kepada manajemen untuk mengarsipkan data yang lebih tua dari satu tahun. Mereka memverifikasi konsep (masalah hukum) dan untungnya kami bisa melakukannya. Jadi kami menghapus tetapi kami juga mengarsipkan data sehingga bisnis masih bisa menjalankan laporan mereka dll.


1

Dalam sebagian besar kasus, Anda harus menyimpan data untuk berjaga-jaga jika diperlukan di masa depan. Bisnis tempat Anda bekerja mungkin ingin melihat data historis untuk mendasarkan keputusan mereka yang akan mengarahkan perusahaan ke arah tertentu.

Anda harus menambahkan kolom 'Date_Time_Removed' ke setiap tabel dan bukannya menghapus secara fisik baris yang Anda atur, tentukan tanggal dan waktu bahwa baris tersebut telah dihapus secara virtual. Kemudian dalam prosedur tersimpan atau sql Anda akan memperhitungkan kolom 'Date_Time_Removed' misalnya pilih bla dari table1 di mana date_time_removed adalah nol

Tentu saja baris yang telah ditambahkan secara tidak sengaja ke database harus dihapus secara permanen, terutama data uji.

Dengan menyimpan semua data yang sah, Anda juga harus menggunakan basis data Anda untuk penyimpanan di masa mendatang.


0

Situasi lain selain yang disajikan adalah ketika data dihapus, tetapi log operasi yang dilakukan dalam database (termasuk penghapusan) disimpan dalam arsip untuk jangka waktu yang lama. Ruang lingkup utama ini adalah menerapkan sistem rollback ke tanggal yang lalu, tetapi juga dapat digunakan untuk menyimpan data yang terhapus dengan cara tertentu (yang dihapus dari basis data, tetapi disimpan dalam arsip).

Menyimpan arsip data yang dihapus tidak akan menjadi masalah besar. Perusahaan besar juga dapat menyimpan versi kode dan banyak informasi lainnya (tidak untuk membicarakan hal-hal terkait non-teknis) sehingga pada akhirnya menyimpan data besar adalah sesuatu yang biasa bagi mereka.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.