Soft Delete: Budi Salah Pencet 'Hapus Akun', Data Siti Hilang Permanen?

Bayangin Budi Jadi Admin Database...

Bayangin Budi kerja jadi Admin di sebuah Startup E-Commerce. Suatu hari, Siti (pelanggan VIP) marah-marah dan minta akunnya dihapus. Budi yang masih *Junior*, langsung buka Terminal MySQL dan ngetik perintah maut: DELETE FROM users WHERE nama = 'Siti'.

Satu detik kemudian, bos Budi lari ke meja Budi sambil panik: "Bud! Kamu hapus akun Siti ya?"
Budi jawab: "Iya Pak, kan dia yang minta."
Bos menepuk jidat: "Aduh! Siti itu pernah transaksi beli barang senilai 100 Juta bulan lalu! Karena akunnya kamu hapus permanen, ID-nya musnah, dan Laporan Keuangan kita bulan lalu jadi cacat (Data yatim piatu)!"

Masalahnya: Hard Delete Menghancurkan Relasi (Sejarah)

Di dunia perbankan atau akuntansi, menghapus baris data secara permanen (Hard Delete) adalah DOSA BESAR. Sekali kamu menghapus data *user*, semua rekam jejak aktivitas mereka (Komentar, Transaksi, Rating) akan kehilangan induknya (Foreign Key rusak). Data itu lenyap selamanya dan tidak bisa di-Restore (dikembalikan) jika ternyata *user* tersebut berubah pikiran.

Nah, Di Sinilah 'Soft Delete' Masuk!

Siti (Senior Developer) mengajari Budi konsep Soft Delete (Hapus Bohongan / Hapus Logis).

• Siti menyuruh Budi membuat satu kolom tambahan di tabel Users bernama: is_deleted (Tipe *Boolean*), atau deleted_at (Tipe *Tanggal*).
• Saat pelanggan minta hapus akun, Backend TIDAK MENGGUNAKAN perintah DELETE FROM.
• Backend menggunakan perintah: UPDATE users SET is_deleted = TRUE WHERE nama = 'Siti'.

Lalu Bagaimana Biar Siti Gak Kelihatan di Aplikasi?
Setiap kali Frontend meminta data *user*, Backend tinggal memfilternya secara rahasia: SELECT * FROM users WHERE is_deleted = FALSE.

Intinya: Bagi *user* (Siti), akunnya seolah-olah sudah musnah dari aplikasi. Tapi bagi perusahaan, data Siti masih duduk manis dan utuh di dalam *database* untuk keperluan Audit Keuangan atau kalau-kalau polisi meminta data transaksi tersebut suatu hari nanti!