Silmek mi, Gizlemek mi? Modern Yazılımda Veri Yönetimi ve Silme Stratejileri

Silmek mi, Gizlemek mi? Modern Yazılımda Veri Yönetimi

Yazılım geliştirme süreçlerinde hepimiz en az bir kez o korkutucu soruyla karşı karşıya kalmışızdır: “Bu veriyi gerçekten silmeli miyim?”

Production ortamında yanlışlıkla çalıştırılan tek bir DELETE komutunun yarattığı domino etkisini hayal edin. Geri dönüşü olmayan bir yola girdiğinizde yedeklerden dönmeye çalışmak saatlerinizi, hatta bazen günlerinizi alabilir. Peki, modern yazılım dünyasında veriyi sistemden tamamen yok etmek (Hard Delete) mi daha mantıklı, yoksa ona sadece bir “görünmezlik pelerini” giydirmek (Soft Delete) mi?

Bu yazıda, veri tabanı mimarisinde kritik bir karar olan silme stratejilerini ve bu stratejilerin sisteminize olan etkilerini inceleyeceğiz.

Hard Delete: Geri Dönüşü Olmayan Köprü

Geleneksel ve en temel yöntem olan Hard Delete, verinin fiziksel olarak diskten temizlenmesi işlemidir. SQL’deki karşılığı meşhur DELETE komutudur.

Neden Tehlikeli?

• Veri Kaybı: Veri bir kez silindiğinde veri tabanı seviyesinde geri dönüşü yoktur.
• İlişkisel Bütünlük (Referential Integrity): Bir müşteriyi sildiğinizde o müşteriye ait geçmiş siparişlerin veya fatura kayıtlarının “yetim” kalmasına neden olursunuz. Bu durum raporlama sistemlerini tamamen bozabilir.
• Hata Payı: İnsan hatasına (yanlış WHERE koşulu gibi) karşı hiçbir savunma mekanizması sunmaz.

Görsel 1: Hard Delete ile verilerin fiziksel olarak diskten silinmesi.

Soft Delete: Dijital Geri Dönüşüm Kutusu

Soft Delete, veriyi fiziksel olarak silmek yerine, tabloda bir işaretçi (flag) kullanarak onu “silinmiş” olarak işaretleme yöntemidir. Veri hâlâ oradadır ancak uygulama katmanında kullanıcıya gösterilmez.

Neden Kullanmalıyız?

• Hata Yönetimi: Yanlışlıkla silinen bir veriyi saniyeler içinde geri getirebilirsiniz. Sadece IsDeleted kolonunu 0 yapmak yeterlidir.
• Veri Analizi: Şirketler için sadece mevcut veri değil, silinen veri de değerlidir. “Kullanıcılar neden bu ürünü listesinden sildi?” gibi soruların cevabı bu gizli verilerde yatar.
• Denetim (Auditing): Verinin ne zaman silindiğini takip edebilir, geçmişe dönük denetimler yapabilirsiniz.

Görsel 2: Soft Delete ile veri kurtarma (Restore) operasyonunun şematik gösterimi.

Teknik Uygulama: Kod Seviyesinde Farklılıklar

Teoriyi pratiğe dökerken aradaki farkı net bir şekilde görebiliriz. Bir “Kullanıcılar” tablosu üzerinden iki yöntemi kıyaslayalım:

• Geleneksel Yöntem: Hard Delete (Fiziksel Silme)

-- Dikkat: Bu işlem kalıcıdır ve geri alınamaz!
DELETE FROM Users
WHERE UserId = 45;

• Modern Yaklaşım: Soft Delete (Mantıksal Silme)

-- Modern Yaklaşım: Soft Delete (Mantıksal Silme)
UPDATE Users
SET
    IsDeleted = 1,
    DeletedAt = GETDATE(),
    ModifiedBy = 'Admin_User' -- İşlemi yapan kişinin bilgisi
WHERE
    UserId = 45 AND IsDeleted = 0; -- Zaten silinmişse tekrar işlem yapma

• Uygulama Katmanında Veriyi Listeleme

-- Aktif (silinmemiş) kullanıcıları listeleme
SELECT
    UserId,
    UserName,
    Email
FROM Users
WHERE IsDeleted = 0;

Stratejik Yaklaşım: Karar Matrisi

Teknik bir kod bloğundan ziyade, hangi durumda hangi yöntemi seçeceğinizi belirleyen bir “Karar Matrisi” üzerinden ilerlemek mimariyi daha sağlam kurmanızı sağlar.

• Geri Alınabilirlik İhtiyacı: Eğer kullanıcı “Yanlışlıkla sildim, geri getirebilir misiniz?” diyebilecekse (örneğin bir blog yazısı veya e-ticaret sepeti) Soft Delete zorunluluktur.
• Yasal Zorunluluklar (GDPR/KVKK): Kullanıcı “Hesabımı tamamen kapat ve tüm verilerimi sil” dediğinde, sisteminizde Soft Delete olsa bile, kişisel verileri fiziksel olarak temizleyen (Hard Delete) veya anonimleştiren bir mekanizma çalışmalıdır.
• Veri Hacmi ve Maliyet: Sürekli büyüyen ve Soft Delete ile işaretlenen veriler, yıllar sonra devasa bir depolama yükü oluşturabilir. Bu durumda “Arşivleme” stratejisi devreye girer: Silinmiş veriler ana veri tabanından alınır ve daha ucuz bir soğuk depolama (Cold Storage) birimine taşınır.

Madalyonun Öteki Yüzü: Dikkat Edilmesi Gerekenler

Soft Delete her ne kadar güvenli görünse de kıdemli bir mühendis gibi düşünmemiz gereken bazı noktalar var:

• Performans: Veriler fiziksel olarak silinmediği için tablo zamanla büyüyecektir. Sorgu hızını korumak için sadece “silinmemiş” verileri hedefleyen indeksler (Filtered Indexes) kullanılmalıdır.
• Benzersizlik (Unique Constraint) Çıkmazı: Bir kullanıcıyı “yumuşak” sildiğinizde e-posta adresi hâlâ veri tabanındadır. Aynı e-posta ile yeni bir kayıt gelirse çakışma yaşanır. Silme anında e-posta alanının yanına bir zaman damgası ekleyerek alanı benzersizlikten kurtarabilirsiniz.

Görsel 3: Modern yazılım mimarilerinde Hard Delete ve Soft Delete yöntemlerinin stratejik kıyaslaması.

Sonuç

“Silmek mi, gizlemek mi?” sorusunun cevabı projenizin ihtiyaçlarında saklı. Finansal kayıtlar, kullanıcı profilleri ve kritik iş verileri için Soft Delete her zaman daha güvenli bir limandır. Ancak geçici loglar veya değersiz veriler için veri tabanını şişirmemek adına Hard Delete kullanmaktan çekinmemelisiniz.

Unutmayın, en iyi sistem hatayı telafi edebilen sistemdir.

Okuduğunuz için teşekkürler!

Kaynakça

• Martin Fowler — Patterns of Enterprise Application Architecture
• SQL Server Documentation — Filtered Index Design Guidelines
• Microsoft Learn — Global Query Filters in Entity Framework Core

YAZAR