Bir müşteri yanlışlıkla önemli bir kaydı sildi ve geri istiyor. Yedekten dönmek tüm veritabanını eskiye çevirmek demek. Kayıt gerçekten silinmediyse ise tek bir güncelleme yeterli.
Bu yazı, yumuşak silme desenini ve maliyetlerini ele alıyor.
Nasıl Çalışır?
Kayıt tablodan çıkarılmaz, işaretlenir:
- Bir silinme tarihi sütunu eklenir.
- Silme işlemi bu sütunu doldurur.
- Sorgular bu kayıtları dışarıda bırakır.
- Geri alma tek güncelleme ile yapılır.
Üçüncü madde tüm yaklaşımın zayıf noktasıdır: silinmiş kayıtları dışarıda bırakma sorumluluğu her sorguya düşer — ve bir sorguda unutulursa silinmiş veri kullanıcıya görünür.
Bu unutma, en sık raporlarda ve doğrudan yazılmış sorgularda yaşanır.
Birinci maddede tarih sütunu tercih edilmelidir. Basit bir doğru-yanlış sütunu, ne zaman silindiğini kaybettirir.
Ne Kazandırır?
| Kazanım | Değeri |
|---|---|
| Kazara silmeyi geri alma | Destek yükünü düşürür |
| İlişkisel bütünlük korunur | Bağlı kayıtlar kırılmaz |
| Denetim izi | Ne silindi, ne zaman |
| Geçmiş raporlar bozulmaz | Eski veriler açıklanabilir |
İkinci satır çoğu zaman asıl gerekçedir: bir ürünü gerçekten silmek, o ürünü içeren geçmiş siparişleri kırar — sipariş kaydı var ama hangi ürün olduğu bilinmez hâle gelir.
Yumuşak silme bu bağlantıyı korur; ürün listede görünmez ama geçmiş siparişte adı okunabilir.
Dördüncü satır ise finansal raporlarda kritiktir. Geçen yılın satış raporu, bugün silinmiş bir ürün yüzünden değişmemelidir.
Gerçek Maliyetler
- Her sorguya filtre eklenmeli.
- Tablo sürekli büyür.
- Benzersizlik kısıtları bozulur.
- Dizin verimliliği düşer.
Üçüncü madde çok yaşanan ve şaşırtan bir sorundur: bir e-posta adresini benzersiz tutan bir kısıt, o kaydı yumuşak sildiğinizde hâlâ geçerlidir — kullanıcı aynı adresle tekrar kayıt olamaz çünkü eski kayıt tabloda durmaktadır.
Çözüm, benzersizlik kısıtını silinme durumunu da içerecek şekilde tanımlamak veya kısmi dizin kullanmaktır.
İkinci madde ise zamanla performansı etkiler. Silinmiş kayıtlar tabloda birikir ve her sorgu onları da atlamak zorunda kalır.
Dördüncü madde bununla ilgilidir; dizinler silinmiş kayıtları da içerdiği için büyür ve yavaşlar.
Filtreyi Unutmamak
En büyük risk budur ve yapısal olarak çözülmelidir:
- Çerçeve desteğini kullanın. Otomatik filtre.
- Görünüm tanımlayın. Filtreli sanal tablo.
- Kod incelemesinde kontrol edin.
İkinci madde en dayanıklı çözümdür: silinmemiş kayıtları döndüren bir görünüm oluşturup uygulamanın yalnızca o görünümü kullanmasını sağlamak, filtreyi unutma ihtimalini tamamen ortadan kaldırır.
Ham tabloya erişim yalnızca yönetim ve kurtarma işlemlerinde kullanılır.
Birinci madde ise modern çerçevelerde hazır gelir ama bir tuzağı vardır: doğrudan yazılan ham sorgular bu otomatik filtreyi atlar.
Bu nedenle raporlama sorguları ayrıca gözden geçirilmelidir.
Kalıcı Silme Politikası
Yumuşak silme, hiç silmemek anlamına gelmemelidir:
| Adım | Not |
|---|---|
| Saklama süresi belirleyin | Örneğin 90 gün |
| Süre sonunda kalıcı silin | Zamanlanmış görevle |
| Arşivlenecekleri ayırın | Yasal zorunluluklar |
| Parça parça silin | Kilit oluşturmamak için |
Birinci satır uyum açısından zorunludur: bir kullanıcı verilerinin silinmesini talep ettiğinde yumuşak silme yeterli değildir — veri hâlâ sistemde durduğu için talep karşılanmış sayılmaz.
Bu tür talepler için kalıcı silme veya anonimleştirme uygulanmalıdır.
Dördüncü satır ise operasyonel bir uyarıdır. Yüz binlerce kaydı tek işlemde silmek uzun süreli kilit üretir.
Ne Zaman Kullanmamalı?
- Çok yüksek hacimli günlük tabloları.
- Geçici veri. Oturum, önbellek.
- Hassas kişisel veri.
- Geri alma ihtiyacı olmayan kayıtlar.
Üçüncü madde bir ilke meselesidir: hassas kişisel veri içeren kayıtlarda yumuşak silme, veriyi gereksiz yere sistemde tutmak anlamına gelir ve veri minimizasyonu ilkesine aykırıdır.
Bu tür kayıtlar silindiğinde gerçekten silinmelidir.
Birinci madde ise performans gerekçesidir. Günde milyonlarca satır üreten bir tabloda yumuşak silme, tabloyu yönetilemez hâle getirir.
Dördüncü madde ise gereksiz karmaşıklıktan kaçınmaktır. Her tabloya yumuşak silme eklemek, bakım yükünü boşuna artırır.
Alternatif Desenler
- Arşiv tablosuna taşımak.
- Durum alanı kullanmak.
- Olay kaydı tutmak.
Birinci madde çoğu avantajı korur ve maliyetleri ortadan kaldırır: silinen kaydı ayrı bir arşiv tablosuna taşımak, ana tabloyu temiz ve hızlı tutarken geri alma imkânını da saklar — ve hiçbir sorguya filtre eklemek gerekmez.
Dezavantajı, ilişkisel bağların arşive taşınmamasıdır.
İkinci madde ise iş mantığıyla örtüşen durumlarda daha doğaldır. Bir siparişin "iptal edildi" durumu, silinmiş olmasından daha anlamlıdır.
Üçüncü madde ise en kapsamlı çözümdür ama uygulama karmaşıklığı yüksektir.
Büyüyen tablolar ve arşivleme için yeterli disk kapasitesi gerekir; sanal sunucu kiralama hizmetleri kapsamında disk yükseltmesi ihtiyaca göre yapılabilir.
Sonuç
Yumuşak silmenin asıl değeri geri alma değil, ilişkisel bütünlüktür: bir ürünü gerçekten silmek, o ürünü içeren geçmiş siparişleri kırar. Ama bedeli vardır ve en can sıkıcısı benzersizlik kısıtlarıdır — silinmiş bir kayıt hâlâ tabloda olduğu için kullanıcı aynı e-posta ile tekrar kayıt olamaz. Filtreyi unutma riskini yapısal çözün: silinmemiş kayıtları döndüren bir görünüm oluşturun ve uygulama yalnızca onu kullansın. Ve saklama süresi tanımlayıp kalıcı silmeyi ihmal etmeyin.
Sıkça Sorulan Sorular (SSS)
Yumuşak silme neden kullanılır?
En sık gerekçe ilişkisel bütünlüktür. Bir ürünü gerçekten silmek, o ürünü içeren geçmiş siparişleri kırar — sipariş kaydı var ama hangi ürün olduğu bilinmez hâle gelir. Ayrıca kazara silmeyi geri almayı ve geçmiş raporların bozulmamasını sağlar.
Kullanıcı aynı e-posta ile neden kayıt olamıyor?
Çünkü benzersizlik kısıtı yumuşak silinmiş kayıtları da kapsıyor — eski kayıt hâlâ tabloda duruyor. Çözüm, kısıtı silinme durumunu da içerecek şekilde tanımlamak veya yalnızca silinmemiş kayıtları kapsayan kısmi dizin kullanmaktır.
Filtreyi unutma riskini nasıl kaldırırım?
Silinmemiş kayıtları döndüren bir görünüm oluşturup uygulamanın yalnızca onu kullanmasını sağlayın; ham tabloya erişim sadece yönetim ve kurtarma için kalsın. Çerçevelerin otomatik filtresi yardımcıdır ama doğrudan yazılan ham sorgular onu atlar — raporlama sorgularını ayrıca gözden geçirin.
Veri silme talebini yumuşak silme ile karşılayabilir miyim?
Hayır. Veri hâlâ sistemde durduğu için talep karşılanmış sayılmaz. Bu tür talepler için kalıcı silme veya gerçek anonimleştirme uygulanmalıdır. Genel olarak hassas kişisel veri içeren kayıtlarda yumuşak silme, veri minimizasyonu ilkesine aykırıdır.
