Jangan pernah DELETE data di database
ฝัง
- เผยแพร่เมื่อ 3 ธ.ค. 2024
- Jangan pernah DELETE data di database
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
TH-cam : / programmerzamannow - วิทยาศาสตร์และเทคโนโลยี
![สาวเมืองเพชร - ธีเดช ทองอภิชาติ [Official MV]](http://i.ytimg.com/vi/kEt7F9PvO3I/mqdefault.jpg)
IMO gak semua data cocok pake softdelete. Kalau tidak ada kebutuhan untuk keep history data, it's fine to delete with cascading.
Contoh table users, sure pake softdelete. Tapi untuk table many-to-many relation user_roles? It creates unnecessary complexities, e.g. kalau user demoted dari admin terus suatu saat mau dipromote jadi admin kembali. Jadi harus tambah logic untuk "insert" atau "update" untuk method "assignRole". Untuk case tersebut, lebih baik terapin audit logging.
Dan argument soal "easier debugging" lebih mudah dicover dengan audit trace IMO, karena setiap event perubahan data akan tercatat. Dicombine dengan application logs, kita bisa lihat step by step perubahan data.
ada juga pake cara append only fashion misal ada rowid, case_type, created_date.
case_type untuk ngejelasin state di rownya contoh case_type: new, updated, deleted, dll. cuma jadi agak ribet aja kalo mau agregasi harus pake rank buat cek state terakhir (aktual) per rowid. 3 kolom itu wajib di cluster index
Pak buatin video tahapan pembuatan aplikasi/website secara general dong, misal kayak pembuatan diagram UML, design database, rencana penggunaan tech stack, s.d selesai, kalo di skripsi mh kayak analisa dan perancangan sistem. Kadang bingung kalo bikin website langsung ke coding. Tks
setuju
Udah ada bro, cari aja judulnya "Alur Kerja Pembuatan Aplikasi"
Dulu istilahnya Purging + Archiving, Thanks sudah ada Ide tentang Sharding... Sebenarnya Sharding itu aku denger di teknologi blockchain. Nah aku lagi nyusun neh Database yang bisa Sharding. Dan juga terinspirasi dari teknologi blockchain, bahwa Database juga bisa terdistribusi, di beda LOKASI. Artinya Database Server itu di Cabang-cabang kantor yang beda Kota. Jelas disini konsepnya bukan ONLINE Database terpusat, tapi aku lebih pada Semi Online (BATCH) terdentralisasi... Ini yang rada rumit jika suatu saat Data diSharding, maka di Server Cabang harus melakukan hal yang sama persis. Ini dilakukan pas hari libur aja sih. Simplenya sih dengan mencopy dari Server Pusat kepada cabang2x dengan syarat Data Cabang dan Pusat sudah tersinkronisasi sama.
bener pak, pernah kejadian ada tim programmer gak sengaja kena delete all semua data di table production. akhirnya saya restore kembali dan mendisable query DELETE , tujuan nya agar data history tetap ada dan menggunakan flagging saja untuk softdelete nya.
tambah sedikit mas, hard delete bukan haram ya tapi harus berdasarkan data retention policy. karena ada kondisi dimana kita harus hard delete. bisa jadi karena perjanjian project atau karena memang harus menghemat cost
Mau tanya pak, kira kira untuk update status sebuah proses, setiap update nya itu selalu insert row baru di table, karena untuk tracking histroy status gitu, itu wajar gak sih pak ?
ini juga yang sedang saya terapkan pada aplikasi chat real time saya. saya simpan selama 1 bulan, yang lewat dari 1 bulan dihapus otomatis dari database dengan cron.
Kalo case kayak ini bisa diakalin kayak WhatsApp mas. Mereka save history chat di storage pengguna untuk chat diatas 1 bulan. Di server hanya tersisa chat terbaru saja. Mungkin sulit di implementasikan kalo bentuk web. Tapi kalo di mobile or desktop lebih mudah
@frxldi walau sulit saya sedang terapkan di aplikasi web pwa, dan sudah sampai pada tahap.
* kirim dan terima pesan (teks)
* mulai dan jawab panggilan (suara, video)
* riwayat panggilan
setiap proses atau tindakan semuanya sudah real time untuk semua pengguna, mirip di whatsapp.
kedepannya akan saya tambahkan fitur status, pesan gambar, pesan suara, pesan video, dll. 🙏
menurut aku tergantung case sih, ada kalanya soft delete, ada kalanya pakai hard delete karena datanya gk diperlukan lagi. lalu ada auto backup database, buat rollback ke state lama kalau diperlukan karena suatu hal
terus pakai log buat mencatat perubahan apa yang terjadi di database
dan softdelete ini dapat melanggar privasi pengguna, karena ketika user menghendaki semua datanya dihapus dari aplikasi kita, tapi kita malah tetap menyimpannya secara diam-diam, jadi kalau user menghendaki menghapus semua datanya maka sebagai developer yg baik kita menhard delete, contohnya user pengen menghapus data akun atau kartu kreditnya tapi kita soft delete aja terus di aplikasi kita masih ada datanya, jadinya itu melanggar privasi user tidak boleh
akhirnya ada discordnya 😁
primary key berarti tidak bisa menggunakan autoincrement berarti ya? (kalau yang partition / sharding)
Saya pertama kali tau dan nerapin soft delete karena masalah referential integrity constraints. Waktu itu tentang tabel products dan orders. Ketika product-nya mau dihapus (udah gak jualan product itu lagi), mau gk mau harus pake soft delete. Soalnya kalo pake hard delete gak bakal bisa karena:
1) id product sedang dipakai di tabel orders (melanggar constraint),
2) kalo delete cascade ya semua order yang ada product tersebut bakal ikut kehapus.
tetep bisa pake hard delete kok. caranya, product_id foreign key column-nya dibuat nullable aja. jadi, ketika ada product yang di hard delete, tambahkan logic di kode programnya utk Update Semua Orders yang terkait, dgn product_id nya diset null.. trus gmn nanti muncul-nya di client app? bisa ditulis product name-nya -> Deleted Product.. so far yg gw implement gitu. gw ga pernah pake soft-delete, krn menuh2in database (storage). pasti nambah cost, apalagi kalo sistem-nya punya banyak data, banyak user, intensitas insert datanya tinggi.
@@danurahadi3607 owalahh bisa ya dibuat nullable, saya belum tau waktu itu. Boleh juga tekniknya.. thanks udh sharing bang
@@mayboyx yoii broo.. senang bisa membantu
Pak itu pake aplikasi apa buat presentasi yg kayak video ini ya pak
@@baby_aliens excalidraw
link discord dapatnya dimana pak Eko?
cek di deskripsi
sering pakai tapi baru paham namanya sharding 😆
kalau di saya yg mainly pake firestore:
- delete = haram
- setiap bikin data harus ada deleted: false, ketika hapus jadi deleted: true
@@dadanisme7 bakal lebih bagus kalp make tipe data nullable timestamp.. karna bisa dpt tambahan info kapan dihapus
Ini mah bukan daging lagi, tapi SUM_SUM tulang belakang
drop/delet database Desember 😂