Soft delete vs hard delete: doğru veri yaşam döngüsünü seçin

Soft delete ve hard delete gerçekte ne anlama gelir

“Silme” iki çok farklı şeyi ifade edebilir. Bunları karıştırmak ekiplerin geçmişi kaybetmesine veya gizlilik taleplerini yerine getirememesine yol açar.

Bir hard delete çoğu kişinin hayal ettiği şeydir: satır veritabanından kaldırılır. Sonra sorgularsanız ortadan kaybolmuştur. Bu gerçek bir kaldırmadır, ancak tasarım yapılmazsa referansları (örneğin silinmiş bir müşteriye işaret eden bir sipariş) bozabilir.

Bir soft delete ise satırı tutar ama genellikle deleted_at veya is_deleted gibi bir alanla silinmiş olarak işaretler. Uygulamanız onu yok sayar, ama veri raporlar, destek ve denetimler için hâlâ vardır.

Soft delete vs hard delete arasındaki takas basittir: geçmiş vs gerçek kaldırma. Soft delete geçmişi korur ve “geri almayı” mümkün kılar. Hard delete depolamayı azaltır; bu gizlilik, güvenlik ve yasal kurallar için önemlidir.

Silme yalnızca depolamayı etkilemez. Ekibinizin sonra neyi cevaplayabileceğini değiştirir: geçmiş bir şikayeti anlamaya çalışan destek temsilcisi, faturalamayı uzlaştırmaya çalışan finans ekibi veya kim neyi ne zaman değiştirdiğini inceleyen uyumluluk ekibi. Veriler çok erken kaybolursa raporlar kayar, toplamlar eşleşmez ve soruşturmalar tahmine dönüşür.

Faydalı bir zihinsel model:

• Soft delete bir kaydı günlük görünümlerden gizler ama izlenebilirlik için tutar.
• Hard delete bir kaydı kalıcı olarak kaldırır ve saklanan kişisel veriyi en aza indirir.
• Birçok gerçek uygulama ikisini birlikte kullanır: iş kayıtlarını tutar, gerektiğinde kişisel tanımlayıcıları kaldırır.

Uygulamada, bir kullanıcı hesabını girişleri engellemek ve sipariş geçmişini korumak için soft delete edebilir, sonra saklama süresi veya doğrulanmış bir GDPR silme hakkı talebi sonrasında kişisel alanları hard delete (veya anonimleştirme) yapabilirsiniz.

Hiçbir araç bu kararı sizin yerinize vermez. AppMaster gibi no-code bir platformla bile inşa ediyorsanız, gerçek iş tablosu bazında “silinmiş”in ne anlama geldiğine karar vermek ve her ekran, rapor ve API'nin aynı kuralı takip ettiğinden emin olmak gerekir.

Silmelerin günlük uygulamalarda neden sorun yarattığı

Çoğu ekip silmeleri bir şey ters gittiğinde fark eder. “Basit” bir silme bağlamı, geçmişi ve açıklama yeteneğinizi silebilir.

Hard delete geri alınması zor olduğu için risklidir. Birisi yanlış düğmeye tıklayabilir, otomatik bir iş hata yapabilir veya bir destek yetkilisi yanlış adımları izleyebilir. Temiz yedekler ve net bir geri yükleme süreciniz yoksa bu kayıp kalıcı olur ve iş etkisi hızla görünür.

Kırık referanslar bir sonraki sürprizdir. Bir müşteriyi silersiniz ama siparişleri hâlâ vardır. Şimdi siparişler hiçbir şeye işaret ediyor, faturalar fatura adını gösteremiyor ve portal ilişkili veriyi yüklemeye çalışırken hata veriyor. Foreign key constraints olsa bile “çözüm” daha kötü olabilir: kaskad silmeler beklediğinizden çok daha fazlasını silebilir.

Analitik ve raporlama da karmaşıklaşır. Eski kayıtlar kaybolduğunda metrikler geriye dönük değişir. Geçen ayın dönüşüm oranı kayar, ömür boyu değer düşer ve trend çizgilerinde açıklanamayan boşluklar oluşur. Ekip sayılar hakkında tartışmaya başlar, karar almaya değil.

Destek ve uyumluluk en çok acı veren yerlerdir. Müşteriler “Neden bana fatura kesildi?” veya “Planımı kim değiştirdi?” diye sorar. Kayıt yoksa zaman çizelgesini yeniden inşa edemezsiniz. Temel soruları cevaplayacak denetim izi kaybolur: ne değişti, ne zaman ve kim tarafından.

Soft delete vs hard delete tartışmasının arkasındaki yaygın başarısızlık modları:

• Kazara silmeler veya hatalı otomasyon nedeniyle kalıcı kayıp
• Ebeveyn kayıtların eksik olması ve çocukların yetim kalması (siparişler, ticketlar)
• Tarihsel satırlar kaybolduğu için değişen raporlar
• Geçmiş olmadan cevaplanamayan destek vakaları

Soft delete hangi durumlarda daha iyi varsayılan olmalı

Soft delete, bir kaydın uzun vadeli değeri varsa veya başka verilere bağlıysa genellikle en güvenli tercihtir. Bir satırı kaldırmak yerine deleted_at veya is_deleted ile işaretlersiniz ve normal görünümlerden gizlersiniz. Soft delete vs hard delete kararında bu varsayılan sürprizleri azaltma eğilimindedir.

Bu yaklaşım veritabanında denetim izi gerektiği durumlarda parıldar. Operasyon ekipleri sıklıkla “Bu siparişi kim değiştirdi?” veya “Bu fatura neden iptal oldu?” gibi basit soruları cevaplamaya ihtiyaç duyar. Çok erken hard delete yaparsanız finans, destek ve uyumluluk raporları için gereken delilleri kaybedersiniz.

Soft delete ayrıca “geri almayı” mümkün kılar. Yöneticiler yanlışlıkla kapatılmış bir ticketı geri açabilir, arşivlenmiş bir ürünü geri getirebilir veya yanlış spam raporu sonrası kullanıcı tarafından oluşturulmuş içeriği kurtarabilir. Veriler fiziksel olarak yoksa böyle bir geri yükleme sunmak zordur.

İlişkiler başka büyük bir nedendir. Bir ebeveyn satırını hard delete etmek yabancı anahtar kısıtlamalarını bozabilir veya raporlarda kafa karıştırıcı boşluklar oluşturabilir. Soft delete ile joinler stabil kalır ve tarihsel toplamlar tutarlı (günlük gelir, tamamlanan siparişler, yanıt süresi istatistikleri) olur.

Soft delete, iş kayıtları için sağlam bir varsayılandır: destek ticketları, mesajlar, siparişler, faturalar, denetim logları, etkinlik geçmişi ve kullanıcı profilleri (nihai silme onaylanana kadar) gibi.

Örnek: bir destek temsilcisi hatalı bir notu “siler”. Soft delete ile not normal UI'dan kaybolur, ama şikayet sırasında denetçiler hala inceleyebilir ve finans raporları açıklanabilir kalır.

Hard delete ne zaman zorunludur

Soft delete birçok uygulama için harika bir varsayılandır, ama veriyi saklamanın bile yanlış olduğu zamanlar vardır. Hard delete kaydın gerçekten kaldırıldığı anlamına gelir ve bazen yasal, güvenlik veya maliyet ihtiyaçları için tek seçenek budur.

En net durum gizlilik ve sözleşmesel yükümlülüklerdir. Bir kişi GDPR silme hakkını kullanırsa veya sözleşmeniz belirli bir süre sonra silme vaat ediyorsa, “işaretlenmiş silinmiş” genellikle yeterli sayılmaz. Satırı, ilişkili kopyaları ve kişiye geri dönebilecek tüm tanımlayıcıları kaldırmanız gerekebilir.

Güvenlik başka bir nedendir. Bazı verileri tutmak çok risklidir: ham erişim tokenları, parola sıfırlama kodları, özel anahtarlar, tek kullanımlık doğrulama kodları veya şifrelenmemiş sırlar. Bunları geçmiş için saklamak nadiren riske değer.

Hard delete ölçek için de doğru olabilir. Eski eventlar, loglar veya telemetri gibi devasa tablolarınız varsa soft delete veritabanınızı sessizce büyütür ve sorguları yavaşlatır. Planlı bir temizleme politikası sistemi duyarlı ve maliyeti öngörülebilir tutar.

Hard delete genellikle geçici veriler (cache, oturumlar, taslak importlar), kısa ömürlü güvenlik öğeleri (sıfırlama tokenları, OTP'ler, davet kodları), test/demo hesapları ve yalnızca toplu istatistiklerin gerektiği büyük tarihsel veri kümeleri için uygundur.

Pratik bir yaklaşım iş geçmişini kişisel veriden ayırmaktır. Örneğin faturaları muhasebe için tutun, ama kişiyi tanımlayan kullanıcı profil alanlarını hard-delete veya anonimleştirin.

Ekipler soft delete vs hard delete konusunda tartışıyorsa, basit bir test kullanın: veriyi tutmanın yasal veya güvenlik riski yaratması durumunda hard delete (veya geri döndürülemez anonimleştirme) kazanmalıdır.

Soft delete'i sürpriz yaratmadan modelleme

Soft delete, sıkıcı ve öngörülebilir olduğunda en iyi çalışır. Amaç basittir: kayıt veritabanında kalır, ama uygulamanın normal parçaları onu yokmuş gibi davranır.

Bir silme sinyali seçin ve ne anlama geldiğini netleştirin

Üç yaygın desen görürsünüz: deleted_at zaman damgası, is_deleted bayrağı veya bir durum enum'u. Birçok ekip deleted_at'ı tercih eder çünkü iki soruyu aynı anda yanıtlar: silinmiş mi ve ne zaman oldu.

Zaten birden fazla yaşam döngüsü durumunuz (aktif, beklemede, askıya alınmış) varsa durum enum'u yine işe yarar, ama “deleted”i “archived” ve “deactivated”dan ayrı tutun. Bunlar farklıdır:

• Deleted: normal listelerde görünmemeli ve kullanılamamalı.
• Archived: geçmiş için saklanır, ama “geçmiş” görünümlerinde görünür olabilir.
• Deactivated: geçici olarak devre dışı, genellikle kullanıcı tarafından geri alınabilir.

Benzersiz alanları sorun çıkarmadan ele alın

Soft delete vs hard delete genellikle e-posta, kullanıcı adı veya sipariş numarası gibi benzersiz alanlarda çöker. Bir kullanıcı “silinmiş” olsa ama e-posta hâlâ veritabanında benzersiz olarak duruyorsa aynı kişi yeniden kayıt olamaz.

İki yaygın çözüm: benzersizliği yalnızca silinmemiş satırlara uygulamak veya silme sırasında değeri yeniden yazmak (örneğin rastgele bir sonek eklemek). Hangi yöntemi seçeceğiniz gizlilik ve denetim ihtiyaçlarınıza bağlıdır.

Filtreleme kurallarını açık (ve tutarlı) yapın

Farklı kitlelerin ne görebileceğine karar verin. Yaygın bir kural seti: normal kullanıcılar silinmiş kayıtları asla görmez, destek/yönetici kullanıcılar açık bir etiketle görebilir, ihracatlar/raporlar yalnızca istendiğinde silinmişleri içerir.

“Herkes filtre eklemeyi hatırlar”a güvenmeyin. Kuralı tek bir yerde koyun: viewlar, varsayılan sorgular veya veri erişim katmanınızda. AppMaster ile inşa ediyorsanız, bu genellikle filtreyi uç noktalarınızı ve Business Process'lerinizi nasıl veri getirdiğinde dahil etmektir, böylece silinmiş satırlar kazara yeni bir ekranda ortaya çıkmaz.

Kısa bir dahili notta (veya şema yorumlarında) anlamları yazın. Gelecekteki siz, “deleted”, “archived” ve “deactivated” aynı toplantıda ortaya çıktığında teşekkür edecektir.

Referansları sağlam tutma: ebeveynler, çocuklar ve joinler

Silmeler uygulamaları en sık ilişkiler yoluyla bozar. Bir kayıt nadiren yalnızdır: kullanıcıların siparişleri, ticketların yorumları, projelerin dosyaları vardır. Soft delete vs hard delete arasındaki zor kısım referansları tutarlı tutmakken ürünün ögeleri “gitti” gibi davranmasını sağlamaktır.

Yabancı anahtarlar: başarısızlık modunu kasıtlı seçin

Foreign key'ler kırık referanslardan sizi korur, ama her seçenek farklı bir anlama sahiptir:

• RESTRICT: çocuklar varsa silmeyi engeller.
• SET NULL: silmeye izin verir ama çocukları ayırır.
• CASCADE: çocukları otomatik siler.
• NO ACTION: birçok veritabanında RESTRICT'e benzer, ama zamanlama farklı olabilir.

Soft delete kullanıyorsanız RESTRICT genellikle en güvenli varsayılandır. Satırı tutarsınız, böylece anahtarlar geçerli kalır ve çocukların hiçbir şeye işaret etmesi engellenir.

İlişkilerde soft delete: yetimsiz gizleme

Soft delete genellikle yabancı anahtarları değiştirmez. Bunun yerine, uygulamada ve raporlarda silinmiş ebeveynleri filtrelersiniz. Bir müşteri soft-delete edildiyse faturaları hâlâ doğru şekilde join olmalı, ama ekranlarda müşteri dropdown'ları görünmemelidir.

Ek dosyalar, yorumlar ve etkinlik logları için kullanıcının ne anladığını belirleyin. Bazı ekipler gövdeyi tutar ama riskli parçaları kaldırır: gizlilik gerekiyorsa ek içeriğini bir yer tutucu ile değiştirin, yorumları silinmiş kullanıcıdan gelmiş olarak işaretleyin (veya yazarı anonimleştirin) ve etkinlik loglarını değiştirilemez tutun.

Joinler ve raporlama için açık kurallar gerekir: silinmiş satırlar dahil edilsin mi? Birçok ekip iki standart sorguyu korur: biri “sadece aktif” ve biri “silinmiş dahil”, böylece destek ve raporlama önemli geçmişi kazara gizlemez.

Adım adım: her ikisini de kullanan bir veri yaşam döngüsü tasarlayın

Pratik bir politika genellikle gün içi hatalar için soft delete ve yasal/gizlilik ihtiyaçları için hard delete kullanır. Eğer tek bir karar (soft delete vs hard delete) olarak ele alırsanız, orta yolu kaçırırsınız: bir süre için geçmişi tutun, sonra kalması gerekenleri temizleyin.

Basit 5 maddelik plan

Verileri birkaç kovaya ayırarak başlayın. “Kullanıcı profili” kişiseldir, “işlemler” finansal kayıtlardır ve “loglar” sistem geçmişidir. Her kovanın farklı kuralları olmalı.

Çoğu ekipte işe yarayan kısa plan:

• Veri gruplarını ve sahiplerini tanımlayın, silmeyi onaylayacak kişiyi belirleyin.
• Saklama ve geri yükleme kurallarını belirleyin.
• Kaldırmak yerine anonimleştirilecekleri kararlaştırın.
• Zamanlanmış bir temizleme adımı ekleyin (önce soft delete, sonra zamanla hard delete).
• Her silme, geri yükleme ve temizleme için bir denetim olayı kaydedin (kim, ne zaman, ne ve neden).

Bir senaryoyla somutlaştırma

Bir müşteri hesabını kapatmak istiyor. Kullanıcının giriş yapmasını engellemek ve referansları bozmamak için hesabı hemen soft delete edin. Sonra saklanmaması gereken kişisel alanları (isim, e-posta, telefon) anonimleştirin; muhasebe için gereken kişisel olmayan işlem bilgilerini tutun. Son olarak, bekleme süresinden sonra zamanlanmış bir temizleme işi hâlâ kalan kişisel verileri kaldırır.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Ekipler yanlış yaklaşımdan değil, tutarsız uygulamadan zarar görür. “Teorik olarak soft delete vs hard delete” dokümanınız olabilir ama pratikte “bir ekranda gizle, diğerlerini unut” modeli yaygındır.

Kolay bir hata: silinmiş kayıtları UI'da gizlersiniz ama API, CSV ihracatları, yönetici araçları veya veri senkronizasyon işleri hâlâ onları gösterir. Bir müşteri, “silinmiş” bir kullanıcının bir e-posta listesinde veya mobil aramada göründüğünü fark eder.

Raporlar ve arama başka bir tuzaktır. Rapor sorguları tutarlı filtreleme yapmazsa toplamlar sapar ve panolar güvenilmez hale gelir. En kötü durumlar arka plan işlerinin yeniden indeksleme veya silinmiş öğeleri yeniden gönderme yapmasıdır çünkü aynı kuralları uygulamamışlardır.

Hard delete çok ileri gidebilir. Tek bir kaskad silme siparişleri, faturaları, mesajları ve denetim loglarını silebilir; aslında denetim izi için ihtiyaç duyduğunuz şeyleri yok eder. Hard delete gerekiyorsa neyin kaybolmasına izin verildiğini ve neyin tutulup anonimleştirileceğini açıkça belirtin.

Benzersiz kısıtlar soft delete ile ince acıya yol açar. Bir kullanıcı hesabını silip aynı e-posta ile yeniden kayıt olmak istiyorsa kayıt başarısız olabilir. Bunun için erken plan yapın.

Uyumluluk ekipleri soracaktır: silme olduğunu ve ne zaman olduğunu kanıtlayabiliyor musunuz? “Sanırım silinmişti” birçok veri saklama incelemesinde yeterli gelmez. Bir silme zaman damgası, tetikleyen kişi/araç ve değişmez bir log girişini saklayın.

Göndermeden önce tüm yüzeyi kontrol edin: API, ihracatlar, arama, raporlar ve arka plan işler. Ayrıca tablo tablo kaskadları gözden geçirin ve benzersiz verilerin (e-posta veya kullanıcı adı gibi) yeniden oluşturulmasına izin verilip verilmeyeceğini doğrulayın.

Yayına almadan önce hızlı kontrol listesi

Soft delete vs hard delete seçmeden önce gerçek uygulamanın davranışını, sadece şemayı değil, doğrulayın.

• Geri yükleme güvenli ve öngörülebilir mi? Bir yönetici “geri alırsa” kaydın gerekli ilişkileri ve durumlarıyla doğru şekilde dönmesi, ancak iptal edilmiş erişim tokenları gibi hassas öğeleri canlandırmaması gerekir.
• Sorgular varsayılan olarak silinmiş veriyi gizliyor mu? Yeni ekranlar, ihracatlar ve API'ler silinmiş satırları kazara dahil etmemeli. Bir kural belirleyin ve her yerde uygulayın.
• Referanslar kırılmıyor mu? Yabancı anahtarlar ve joinler yetim kayıt veya yarım kalan ekran üretmemeli.
• Temizleme programı ve sahibi var mı? Soft delete planın yalnızca yarısıdır. Ne zaman verinin kalıcı olarak kaldırılacağı, kimin çalıştıracağı ve nelerin hariç tutulacağı tanımlanmalı (örneğin aktif ihtilaflar).
• Silme diğer hassas işlemler gibi loglanıyor mu? Kimin başlattığını, ne zaman olduğunu ve nedenini kaydedin.

Sonra gizlilik yolunu uçtan uca test edin. Bir GDPR silme hakkı talebini ana veritabanı dışında kopyalar, ihracatlar, arama indexleri, analiz tabloları ve entegrasyonlar dahilinde yerine getirebiliyor musunuz?

Bunu doğrulamanın pratik yolu, staging ortamında bir “kullanıcı sil” kuru çalışması yapmak ve veri izini takip etmektir.

Örnek: faturalama geçmişini korurken bir kullanıcıyı silme

Bir müşteri “Lütfen hesabımı silin” diyor. Sizde ayrıca muhasebe ve chargeback kontrolleri için kalması gereken faturalar var. İşte soft delete vs hard delete pratikte işe yarar: erişimi kaldırıp kişisel detayları silerken işlenmiş finans kayıtlarını tutabilirsiniz.

“Hesap”ı faturalama kaydından ayırın. Hesap giriş ve kimlik ile ilgilidir. Faturalama kaydı zaten yapılmış bir işlemle ilgilidir.

Temiz bir yaklaşım:

• Kullanıcı hesabını soft delete edin, böylece giriş yapamaz ve profil normal görünümlerden kaybolur.
• Faturaları ve ödemeleri aktif kayıtlar olarak tutun, ama onları kişisel alanlara bağlamayı bırakın.
• Kişisel verileri (isim, e-posta, telefon, adres) anonimleştirin; örneğin “Deleted User” gibi nötr bir değer ve kimlik içermeyen dahili bir referansla değiştirin.
• API tokenları, parola hashleri, oturumlar, refresh tokenlar ve kayıtlı cihazlar gibi hassas erişim öğelerini hard delete edin.
• Gerçekte neyin saklanması gerektiğini ve nedenini belgeleyin.

Destek ticketları ve mesajlar genellikle arada kalır. Mesaj içeriği kişisel veriler içeriyorsa, metnin bazı kısımlarını sansürlemeniz, ekleri kaldırmanız ve ticket kabuğunu (zaman damgaları, kategori, çözüm) kalite takibi için tutmanız gerekebilir. Ürününüz mesaj gönderiyorsa (e-posta/SMS, Telegram), kişinin bir daha aranmayacağı şekilde dışa gönderim tanımlayıcılarını da kaldırın.

Destek neyi görebilir? Genellikle fatura numaraları, tarihler, tutarlar, durum ve kullanıcının ne zaman silindiğine dair bir not. Göremeyecekleri şeyler: giriş e-postası, tam ad, adresler, kayıtlı ödeme yöntemi detayları veya aktif oturumlar.

Sonraki adımlar: kuralları belirleyin, sonra tutarlı uygulatın

Silme kararları yazılı ve ürünün her yerinde aynı şekilde uygulandığında kalıcı olur. Soft delete vs hard delete sorusunu önce bir politika meselesi olarak ele alın, kod hilesi olarak değil.

Herkesin okuyabileceği basit bir veri saklama politikası ile başlayın. Ne tuttuğunuzu, ne kadar süre tuttuğunuzu ve nedenini söylemelidir. “Neden” çatışan hedeflerde neyin kazanacağını söyler (örneğin destek geçmişi vs gizlilik talepleri).

İyi bir varsayılan genellikle şöyledir: günlük iş kayıtları için soft delete, gerçekten hassas veriler (tokenlar, sırlar) için hard delete ve saklanmaması gereken her şey için hard delete.

Politika netleşince, onu uygulayan akışları kurun: geri yükleme için bir “çöp” görünümü, kontrollerden sonra geri döndürülemez silme için bir “temizleme kuyruğu” ve kim ne zaman ne yaptığını gösteren bir denetim görünümü. “Temizle”yi “sil”den daha zor yapın ki kazara kullanılmasın.

AppMaster (appmaster.io) içinde bunu uyguluyorsanız, Data Designer'da soft-delete alanları modellemek ve silme/geri yükleme/temizleme mantığını tek bir Business Process'te merkezileştirmek, ekranlar ve API uç noktalarının aynı kuralları izlemesine yardımcı olur.