Yumuşak Silme: Kaydı Silmek Yerine İşaretlemek
Bir müşteri yanlışlıkla siparişini sildi ve geri getirmenizi istiyor. Yedeğiniz dünden kalma; geri yüklerseniz bugünkü tüm veriyi kaybedeceksiniz. Bu ikilem, silme işlemini nasıl tasarladığınızla ilgilidir.
Bu yazı, kalıcı silme ile işaretleyerek silme arasındaki tercihi ele alıyor.
İki Yaklaşım
| Kalıcı silme | İşaretleyerek silme |
|---|---|
| Satır tablodan gider | Satır kalır, işaretlenir |
| Geri alınamaz | Geri alınabilir |
| Tablo küçülür | Tablo büyümeye devam eder |
| İlişkiler kopar | İlişkiler korunur |
Dördüncü satır en çok fark yaratan noktadır: bir müşteri kaydını kalıcı sildiğinizde ona bağlı geçmiş siparişler sahipsiz kalır ve raporlarınız "bilinmeyen müşteri" satırlarıyla dolar — işaretleme yönteminde ilişki bozulmaz.
Bu nedenle geçmişi olan kayıtlar genellikle işaretlenerek silinir.
Üçüncü satır ise işaretlemenin bedelini gösterir; tablo hiç küçülmez.
Bu bedel, sonraki bölümlerde ele alınan sorunları doğurur.
Basit Kurulum
- Tabloya silinme zamanı sütunu eklenir.
- Silme işlemi bu sütunu doldurur.
- Sorgular boş olanları getirir.
Birinci maddede bilinçli bir seçim vardır: silindi mi sorusunu evet-hayır olarak değil, silinme zamanı olarak saklamak hem aynı bilgiyi verir hem de ne zaman silindiğini kaydeder — ek maliyeti yoktur ve sonradan çok işe yarar.
Kimin sildiğini de saklamak denetim açısından değerlidir.
Üçüncü madde ise en kritik noktadır ve bir sonraki bölümde ayrıntılandırılıyor.
Bu filtreyi unutmak, silinmiş kayıtların yeniden görünmesi demektir.
Unutulan Filtre Riski
- Her sorguya koşul eklenmeli.
- Unutulan bir sorgu silinmişi gösterir.
- Merkezî bir katman güvenlidir.
İkinci madde bu yöntemin en büyük riskidir: yeni yazılan bir raporda filtreyi eklemeyi unutmak, silinmiş kayıtların müşteriye tekrar görünmesine yol açar ve bu hata çoğu zaman aylar sonra fark edilir.
Hata sessizdir; hiçbir uyarı üretmez.
Üçüncü madde çözümü verir. Veri erişimi tek bir katmandan geçiyorsa filtre orada bir kez uygulanır.
Doğrudan sorgu yazılan yerlerde ise kontrol listesi kaçınılmazdır.
Benzersizlik Çakışması
| Senaryo | Sonuç |
|---|---|
| Kullanıcı hesabı silinir | Satır durur |
| Aynı e-posta ile kayıt denenir | Benzersizlik hatası |
| Kullanıcı sebebi anlamaz | Destek talebi |
İkinci satır sık yaşanan bir çıkmazdır: silinmiş bir hesabın e-posta adresi tabloda durduğu için aynı adresle yeni kayıt açılamaz — kullanıcıya "bu adres kullanımda" denir ama ortada görünen bir hesap yoktur.
Çözüm, benzersizlik kuralını silinme durumuyla birlikte tanımlamaktır.
Alternatif olarak silme anında adres değiştirilebilir ama bu geri almayı zorlaştırır.
Karar, geri alma ihtiyacının ne kadar gerçek olduğuna bağlıdır.
Performans Etkisi
- Tablo hiç küçülmez.
- Her sorguya ek koşul girer.
- Dizinler bunu hesaba katmalı.
Üçüncü madde pratik bir düzeltme sunar: silinme sütunu neredeyse her sorguda kullanıldığı için mevcut dizinlere dahil edilmelidir — aksi hâlde veritabanı dizinden gelen satırları teker teker kontrol etmek zorunda kalır.
Silinmiş kayıt oranı yükseldikçe bu maliyet artar.
Birinci madde ise uzun vadeli sorundur; yıllar içinde tablonun yarısı silinmiş kayıt olabilir.
Bu noktada arşivleme devreye girer.
Kalıcı Silmeye Geçiş
- Belirli süre sonra kalıcı silin.
- Veya arşiv tablosuna taşıyın.
- Süreyi politika olarak belirleyin.
Üçüncü madde hem teknik hem hukuki bir gerekliliktir: silinmiş verinin ne kadar süre saklanacağı belirsizse, hem tablo sonsuza kadar büyür hem de kullanıcı silme talebini gerçekten karşılamamış olursunuz.
Otuz gün, çoğu senaryo için makul bir süredir.
Süre dolduğunda düzenli bir görev kayıtları kalıcı olarak siler.
Bu, çöp kutusu davranışının doğal karşılığıdır.
Her Tabloda Gerekli mi
| Tablo | Yumuşak silme |
|---|---|
| Sipariş, fatura | Gerekli |
| Kullanıcı hesabı | Gerekli |
| Oturum kaydı | Gereksiz |
| Geçici önbellek | Gereksiz |
Üçüncü ve dördüncü satırlar önemli bir ayrımı gösterir: yumuşak silme yalnızca geri getirilmesi anlamlı olan veriler için kurulmalıdır — oturum veya önbellek kayıtlarını işaretleyerek saklamak, hiçbir fayda sağlamadan tabloyu şişirir.
Her tabloya aynı deseni uygulamak yaygın bir aşırılıktır.
Karar, "bu kayıt yanlışlıkla silinirse birileri geri ister mi" sorusuyla verilir.
Cevap hayırsa kalıcı silme daha basit ve daha hızlıdır.
Arayüz Tarafı
- Silme işlemi geri alınabilir bildirimi göstersin.
- Çöp kutusu ekranı sunun.
- Kalıcı silme ayrı onay istesin.
Birinci madde kullanıcı deneyimini belirgin biçimde iyileştirir: silme sonrası birkaç saniye görünen bir geri alma bağlantısı, onay penceresinden daha etkilidir — çünkü onay penceresi zaten refleksle kapatılır.
Bu davranış, yumuşak silmenin kullanıcıya yansıyan yüzüdür.
İkinci madde ise destek yükünü azaltır; kullanıcı kendi kaydını geri getirebilir.
Üçüncü madde, gerçekten geri dönüşü olmayan işlem için bilinçli bir onay sağlar.
Büyüyen tablolar ve düzenli temizlik görevleri için istikrarlı bir barındırma altyapısı gerekir; Linux hosting hizmeti ile zamanlanmış görevlerinizi ve veritabanınızı aynı yerde yönetebilirsiniz.
Sonuç
İşaretleyerek silme, geçmişi olan kayıtlar için doğru tercihtir çünkü bir müşteri kaydını kalıcı sildiğinizde ona bağlı geçmiş siparişler sahipsiz kalır. Ama bedeli vardır: en büyük risk, yeni yazılan bir sorguda filtreyi eklemeyi unutmaktır ve bu hata sessizdir. Her tabloya uygulamayın, silinme sütununu dizinlere ekleyin ve belirli bir süre sonunda kalıcı silmeyi planlayın.
Sıkça Sorulan Sorular (SSS)
Neden kaydı doğrudan silmemeliyim?
Geçmişi olan kayıtlarda ilişkiler kopar. Bir müşteri kaydını kalıcı sildiğinizde ona bağlı siparişler sahipsiz kalır ve raporlarınız "bilinmeyen müşteri" satırlarıyla dolar. Oturum veya önbellek gibi geri getirilmesi anlamsız kayıtlarda ise kalıcı silme daha doğrudur.
Yumuşak silmenin en büyük riski nedir?
Filtreyi unutmak. Yeni yazılan bir raporda silinme koşulunu eklemeyi unutmak, silinmiş kayıtların müşteriye tekrar görünmesine yol açar ve bu hata çoğu zaman aylar sonra fark edilir. Veri erişimini tek bir katmandan geçirmek en güvenli çözümdür.
Silinen kullanıcı aynı e-posta ile kayıt olamıyor?
Silinmiş hesabın adresi tabloda durduğu için benzersizlik kuralı engelliyor. Kullanıcıya "bu adres kullanımda" denir ama görünen bir hesap yoktur. Çözüm, benzersizlik kuralını silinme durumuyla birlikte tanımlamaktır.
Silinmiş kayıtları ne kadar saklamalıyım?
Bir politika belirleyin; otuz gün çoğu senaryo için makuldür. Süre belirsizse hem tablo sonsuza kadar büyür hem de kullanıcının silme talebini gerçekten karşılamamış olursunuz. Süre dolduğunda düzenli bir görev kayıtları kalıcı silmelidir.
