Ujang Ganti Nomor Rekening, Yang ke-update Nomor Rekening Ujang yang Lain
2025-05-02
cia-for-developerDi suatu sistem, ada banyak user namanya Ujang:
Ujang A Ujang B Ujang yang pake titik Ujang yang pake spasi
Suatu hari, Ujang A update nomor rekening. Dan tiba-tiba...
π₯ Nomor rekening Ujang B ikut berubah π₯ Ujang yang lain ikut kena imbas π₯ Dan semuanya bilang: βLah ini rekening siapa?β
Sql
UPDATE accounts
SET account_number = '987654321'
WHERE name LIKE 'Ujang%';
π§ Maksudnya sih baik. Tapi gak semua Ujang itu Ujang yang sama.
Kalau WHERE
di query-mu terlalu generik, jangan kaget kalau data yang berubah lebih banyak dari yang kamu niatkan.
Semua Ujang di database punya nomor rekening yang sama.
Pas hari payroll:
π§Ύ 100 transaksi gaji πΈ Semuanya nyasar ke Ujang A π‘ Sisa Ujang: ngamuk π΅βπ« Ujang A: bingung π₯ Tim finance: burn out
Ini bukan data bocor. Bukan juga data hilang.
Tapi data berubah dengan salah.
Dan gak ada yang sadar β karena sistem bilang: βupdate sukses.β
Itulah Integrity. Kalau dia gak dijaga, data bisa jadi bohong massal.
Ini contoh, problem integrity nggak harus karena kena hack. Bisa terjadi dari bug kecil, query ceroboh, atau proses yang gak validasi.
Invoice total dihitung ulang setiap load page, tapi data yang dipakai berubah. Akibatnya, jumlah tagihan makin lama makin gede β padahal user gak ngapa-ngapain.
Data mentahnya bener, tapi karena ETL gagal update dengan benar, grafiknya ngawur. Manajemen ambil keputusan dari data yang salah.
Backup kelihatan sukses, tapi saat restore, ID antar tabel gak sinkron. User A dapet histori milik User B.
Bug rounding error bikin harga produk berubah dari 49.999 jadi 0. Akhirnya customer checkout ratusan item secara βgratisβ.
Integrity bukan cuma di database. Bisa rusak di frontend, pipeline, bahkan saat backup & restore.
Kelakuan | Efeknya |
---|---|
Update data pake name LIKE | Semua user dengan nama mirip ikut kena |
Gak validasi user ownership sebelum update | User bisa ubah data milik orang lain |
Nggak cek impacted rows | Data berubah tapi gak tahu seberapa luas efeknya |
Update langsung ke DB tanpa review | Bug bisa langsung korupkan data penting |
Langkah-langkah ini bisa bantu kamu mencegah kerusakan data yang gak kelihatan tapi fatal.
Best Practice | Kenapa Penting |
---|---|
Selalu pakai identifier unik seperti user_id | Data diubah tepat sasaran |
Validasi user ownership sebelum update | Cegah manipulasi data orang lain |
Gunakan transaction + rollback | Kalau gagal, data tetap utuh |
Logging semua perubahan sensitif | Bisa ditelusuri kalau ada yang aneh |
Cek impacted rows + tampilkan ke user | Biar tahu seberapa banyak yang berubah |
Review query penting bareng tim | Satu orang bisa salah, bareng-bareng lebih aman |
Apa itu Integrity? Menjaga agar data tetap utuh, akurat, dan tidak berubah secara tak sah.
Kenapa penting? Karena kalau data bisa berubah seenaknya, sistem jadi gak bisa dipercaya.
Jangan tunggu semua Ujang di database panik. Integrity itu bukan fitur tambahan β itu fondasi kepercayaan sistem.
Konten Terkait :