Soft Delete
Neden Soft Delete Kullanırız?
Bir kaydı DELETE FROM users WHERE id=1; ile fiziksel olarak sildiğinde veri tamamen kaybolur.
Gerçek dünyada:
- Kullanıcı yanlışlıkla silme yapabilir
- Hukuki gereksinimler olabilir
- Geçmiş raporlar için veri saklanmalıdır
- İlişkisel bütünlük korunmalıdır
Soft Delete, veriyi fiziksel olarak silmek yerine mantıksal olarak silinmiş işaretlemektir.
Kullanmazsak Ne Olur?
- Yanlış silinen veri geri getirilemez
- Raporlar bozulur
- Foreign key ilişkileri anlamsızlaşır
- “Sahipsiz” kayıtlar oluşabilir
Örneğin:
Kullanıcı silindi → Eski siparişleri kime ait?
Nasıl Yapılır?
Tabloya bir kolon eklenir:
deleted_at TIMESTAMP NULLveyais_deleted BOOLEAN
Örnek
UPDATE users
SET deleted_at = NOW()
WHERE id = 1;
Sorgular:
SELECT *
FROM users
WHERE deleted_at IS NULL;
Kritik Nokta
Soft delete kullandığında tüm SELECT sorgularına otomatik filtre eklenmelidir:
WHERE deleted_at IS NULL
Bunu:
- Middleware
- Repository layer
- ORM global scope
- Sequelize
paranoid: true
ile otomatik hâle getirmek gerekir.
Aksi halde silinen veriler her yerde görünür.
Soft Delete vs Status
| Alan | Anlamı |
|---|---|
| status | Business state (aktif, blokeli, beklemede) |
| updated_at | Son değişiklik zamanı |
| deleted_at | Lifecycle event (silinme zamanı) |
Önemli nokta:
Soft delete bir state değildir. Bir lifecycle event’tir.
Lifecycle = Kaydın zaman çizelgesindeki olayları.
Silme işlemi:
- İş yaşam döngüsünden çıkışı temsil eder
- Ancak soft delete sayesinde geri alınabilir
Soft Delete'in Bedeli
- Veritabanı büyür
- Index maliyeti artar
- Sorgular daha karmaşık olur
Çözüm:
- Arşivleme
- Periodic cleanup
- Partitioning
Audit Logs
Neden Audit Log Kullanırız?
Sorular:
- Bu kullanıcının şifresini kim değiştirdi?
- Bu ürünün fiyatını kim güncelledi?
- Bu siparişi kim iptal etti?
Audit Log = Hesap verebilirlik (Accountability)
Kullanmazsak Ne Olur?
- Güvenlik ihlali tespit edilemez
- Veri tutarsızlığı kaynağı bulunamaz
- Sistem kara kutuya dönüşür
- Hukuki sorunlarda kanıt üretilemez
Ne Kaydederiz?
| Alan | Açıklama |
|---|---|
| entity_type | user / order / payment |
| entity_id | 123 |
| action | CREATE / UPDATE / DELETE |
| old_value | JSON (önceki veri) |
| new_value | JSON (yeni veri) |
| user_id | işlemi yapan |
| ip_address | IP |
| created_at | zaman |
Örnek Audit Log
{
"entity": "users",
"entity_id": 5,
"action": "UPDATE",
"old_value": { "email": "a@mail.com" },
"new_value": { "email": "b@mail.com" },
"user_id": 12,
"created_at": "2026-01-05 14:30"
}
Soft Delete + Audit Flow
User “Delete” tuşuna bastı
↓
Soft delete yapıldı (deleted_at set)
↓
Audit log yazıldı
Aralarındaki Fark
| Soft Delete | Audit Log |
|---|---|
| Veri güvenliği | Hesap verebilirlik |
| Mantıksal silme | Değişim geçmişi |
| Geri alınabilir | İzlenebilirlik |
Best Practice
- Soft delete ile veri kaybını önle
- Audit log ile sistem davranışını kaydet
- İkisini birlikte kullan