Veritabanı kaydının fiziksel mi yoksa mantıksal / yumuşak silinmesi mi?

Kaydı fiilen veya fiziksel olarak silmek yerine, bir kaydı mantıksal / yazılımsal olarak silmenin (yani kaydın silindiğini belirten bir işaret koymanın) avantajı nedir?

Bu yaygın bir uygulama mı?

Bu güvenli mi?

Avantajları, geçmişi saklamanızdır (denetim için iyidir) ve sildiğiniz satıra başvuran veritabanındaki diğer çeşitli tablolar arasında bir silme işleminin basamaklandırılması konusunda endişelenmenize gerek yoktur. Dezavantajı, bayrağı hesaba katmak için herhangi bir raporlama / görüntüleme yöntemini kodlamanız gerekmesidir.

Yaygın bir uygulama olduğu sürece - evet derdim, ancak her şeyde olduğu gibi, bunu kullanıp kullanmayacağınız iş ihtiyaçlarınıza bağlıdır.

DÜZENLEME: Başka bir dezavantaj düşünülmüş - Tabloda benzersiz dizinleriniz varsa, silinen kayıtlar yine de "bir" kaydı alacaktır, bu nedenle bu olasılık etrafında kodlamalısınız (örneğin, üzerinde benzersiz bir dizine sahip bir Kullanıcı tablosu) kullanıcı adı; Silinen bir kayıt, silinen kullanıcıların kullanıcı adlarını yeni kayıtlar için engellemeye devam eder.Bunun etrafında çalışarak, bir GUID'yi silinen kullanıcı adı sütununa yapıştırabilirsiniz, ancak bu, tavsiye etmeyeceğim çok karmaşık bir çözümdür. Muhtemelen bu durumda olurdu Bir kullanıcı adı kullanıldığında asla değiştirilemeyecek bir kurala sahip olmak daha iyidir.)

Mantıksal silmeler yaygın bir uygulama mıdır? Evet bunu birçok yerde gördüm. Güvende mi? Bu gerçekten, verilerin siz onu silmeden önce olduğundan daha mı az güvenli olduğuna bağlıdır?

Bir Teknoloji Lideri olduğumda, ekibimizden her veri parçasını saklamasını talep etmiştim, o sırada tüm bu verileri çeşitli BI uygulamaları oluşturmak için kullanacağımızı biliyordum, ancak o sırada gereksinimlerin ne olacağını bilmiyorduk. olmak. Bu denetim, sorun giderme ve raporlama açısından iyi olsa da (Bu, B2B işlemleri için bir e-ticaret / araçlar sitesiydi ve birisi bir araç kullanmışsa, hesabı daha sonra kapatılsa bile kaydetmek istedik), birçok dezavantajı vardı.

Olumsuz taraflar şunları içerir (daha önce bahsedilen diğerleri dahil değildir):

1. Tüm bu verileri tutmanın performans sonuçları, çeşitli arşivleme stratejileri geliştiriyoruz. Örneğin, uygulamanın bir alanı, haftada yaklaşık 1 Gb veri üretmeye yaklaşıyordu.
2. Verileri tutmanın maliyeti zamanla artar, disk alanı ucuzken, terabaytlarca veriyi hem çevrimiçi hem de çevrimdışı tutmak ve yönetmek için gereken altyapı miktarı çok fazladır. Yedekleme için çok fazla disk gerekir ve yedeklemelerin hızlı bir şekilde hareket etmesini sağlamak için insanların zamanı vb.

Mantıksal, fiziksel silme veya arşivlemeyi kullanmaya karar verirken kendime şu soruları sorardım:

1. Bu, tabloya yeniden eklenmesi gerekebilecek veriler mi? Örneğin, bir kullanıcı hesabını etkinleştirebileceğiniz veya devre dışı bırakabileceğiniz için Kullanıcı Hesapları bu kategoriye uyar. Bu durumda mantıksal silme en mantıklı olanıdır.
2. Verileri depolamanın kendine özgü bir değeri var mı? Eğer öyleyse ne kadar veri üretilecek. Buna bağlı olarak ya mantıksal bir silme ile giderim ya da bir arşivleme stratejisi uygularım. Mantıksal olarak silinen kayıtları her zaman arşivleyebileceğinizi unutmayın.

Biraz geç olabilir, ancak herkesin Pinal Dave'in mantıksal / yumuşak silme hakkındaki blog gönderisine bakmasını öneririm :

Ben sadece bu tür bir tasarımı [yumuşak silme] hiç sevmiyorum. Sadece gerekli verilerin tek tabloda olması ve gereksiz verilerin arşivlenmiş bir tabloya taşınması gereken mimariye kesinlikle inanıyorum. İsDeleted sütununu takip etmek yerine, iki farklı tablonun kullanılmasını öneriyorum: biri siparişli diğeri silinmiş siparişli. Bu durumda, her iki tabloyu da tutmanız gerekecektir, ancak gerçekte bakımı çok kolaydır. İsDeleted sütununa UPDATE deyimi yazdığınızda, INSERT INTO başka bir tablo yazın ve orijinal tablodan SİLİN. Durum geri dönme ise, başka bir INSERT INTO yazın ve ters sırada SİL. Başarısız bir işlemden endişe ediyorsanız, bu kodu TRANSACTION içine sarın.

Yukarıda açıklanan durumlarda daha küçük masa ve daha büyük masanın avantajları nelerdir?

• Daha küçük bir tablonun bakımı kolaydır
• Dizin Yeniden oluşturma işlemleri çok daha hızlıdır
• Arşiv verilerinin başka bir dosya grubuna taşınması, birincil dosya grubunun yükünü azaltacaktır (tüm dosya gruplarının farklı sistemde olduğu göz önünde bulundurulduğunda) - bu aynı zamanda yedeklemeyi de hızlandıracaktır.
• Daha küçük boyut nedeniyle istatistikler sık ​​sık güncellenecek ve bu daha az kaynak gerektirecektir.
• Dizinin boyutu daha küçük olacaktır
• Daha küçük bir masa boyutu ile masanın performansı artacaktır.

Ben bir NoSQL geliştiricisiyim ve son işimde, birisi için her zaman kritik olan verilerle çalıştım ve yaratıldığı gün kazayla silindiyse, onu son yedeklemede bulamadım dünden! Bu durumda, yumuşak silme her zaman günü kurtarır.

Zaman damgalarını kullanarak, belgenin silindiği tarihi kaydederek yazılımla silme işlemi yaptım:

IsDeleted = 20150310  //yyyyMMdd

Her Pazar, bir işlem veri tabanında yürüdü ve IsDeletedalanı kontrol etti . Geçerli tarih ile zaman damgası arasındaki fark N günden fazlaysa, belge kalıcı olarak silinmiştir. Belgenin hala bazı yedeklemelerde mevcut olduğu düşünüldüğünde, bunu yapmak güvenliydi.

DÜZENLEME: Bu NoSQL kullanım örneği, veritabanında oluşturulan büyük belgelerle ilgilidir, her gün onlarca veya yüzlerce, ancak binlerce veya milyonlarca değil. Genel olarak, iş akışı süreçlerinin durumu, verileri ve eklerini içeren belgelerdi. Bir kullanıcının önemli bir belgeyi silme ihtimalinin olmasının nedeni buydu. Bu kullanıcı, Yönetici ayrıcalıklarına sahip biri veya belki de belgenin sahibi olabilir, sadece birkaç isim.

TL; DR Benim kullanım durumum Büyük Veri değildi. Bu durumda farklı bir yaklaşıma ihtiyacınız olacak.

Kullandığım modellerden biri, bir ayna tablosu oluşturmak ve birincil tabloya bir tetikleyici eklemek, böylece tüm silmeler (ve istenirse güncellemeler) yansıtma tablosuna kaydedilir.

Bu, silinen / değiştirilen kayıtları "yeniden yapılandırmanıza" olanak tanır ve yine de birincil tabloda kalıcı olarak silebilir ve onu "temiz" tutabilirsiniz - aynı zamanda bir "geri alma" işlevinin oluşturulmasına olanak tanır ve ayrıca tarihi, saati de kaydedebilirsiniz ve ayna masasında eylemi gerçekleştiren kullanıcı (cadı avı durumlarında paha biçilmez).

Diğer bir avantaj ise, yansıtma tablosundan kayıtları dahil etme zahmetine kasıtlı olarak girmediğiniz sürece birincil kayıt sorgulanırken yanlışlıkla silinen kayıtları dahil etme şansının olmamasıdır (canlı ve silinmiş kayıtları göstermek isteyebilirsiniz).

Diğer bir avantaj, ayna tablonun, herhangi bir gerçek yabancı anahtar referansına sahip olmaması gerektiğinden bağımsız olarak temizlenebilmesidir; bu, yumuşak silmeleri kullanan ancak yine de diğer tablolara referans bağlantıları olan bir birincil tablodan temizleme ile karşılaştırıldığında bunu nispeten basit bir işlem haline getirir.

Başka ne gibi avantajları var? - projede çalışan bir grup kodlayıcınız varsa, veri tabanında karışık becerilerle ve detay seviyelerine dikkat ederek okumalar yapıyorsanız harika, içlerinden birinin silinmemeyi unutmamasını umarak geceleri uyanık kalmanız gerekmez. Kayıtlar (lol, Silinmiş Kayıtları Dahil Etme = Doğru), bu durum, müşterilerin daha sonra bir miktar hisse satın aldıklarını söyleyen mevcut nakit pozisyonunu (yani, bir ticaret sisteminde olduğu gibi) söylemesi gibi şeylerle sonuçlanır. Başlangıçta biraz daha fazla "ek yük" e sahip olsalar bile, sağlam çözümlerin değerini çok çabuk öğreneceklerdir.

İstisnalar:
- bir kılavuz olarak, kullanıcı, kategori vb. "Referans" verileri için yumuşak silmeleri ve "olgu" tipi veriler için bir ayna tablosuna sabit silmeleri, yani işlem geçmişini kullanın.

Genelde mantıksal silme işlemlerini kullanıyorum - 'Silinen' verileri aralıklı olarak arşivlenmiş bir tabloya arşivlediğinizde (gerekirse aranabilir), dolayısıyla uygulamanın performansını etkileme şansı olmadığında iyi çalıştığını görüyorum.

İyi çalışıyor çünkü daha önce denetlendiyseniz hala verilere sahipsiniz. Fiziksel olarak silerseniz, kaybolur !

Özellikle bir İş Kolu uygulaması veya kullanıcı hesapları bağlamında mantıksal silme işleminin büyük bir hayranıyım. Sebeplerim basit: çoğu zaman bir kullanıcının artık sistemi kullanmasını istemiyorum (bu nedenle hesap silinmiş olarak işaretleniyor), ancak kullanıcıyı silersek, tüm çalışmalarını kaybederiz.

Diğer bir yaygın senaryo, kullanıcıların silindikten bir süre sonra yeniden oluşturulabilmesidir. Kullanıcı için tüm verilerini yeniden oluşturmak yerine, silinmeden önceki haliyle sunması çok daha hoş bir deneyimdir.

Genelde kullanıcıları daha çok silmeyi onları süresiz olarak "askıya almak" olarak düşünüyorum. Ne zaman yasal olarak geri dönmeleri gerektiğini asla bilemezsiniz.

Neredeyse her zaman yumuşak silerim ve işte nedeni:

• Bir müşteri sizden isterse silinen verileri geri yükleyebilirsiniz. Yumuşak silmelerle daha mutlu müşteriler. Yedeklemelerden belirli verileri geri yüklemek karmaşıktır
• isdeletedher yeri kontrol etmek bir sorun değildir, useridyine de kontrol etmeniz gerekir (eğer veritabanı birden fazla kullanıcıdan veri içeriyorsa). Bu iki kontrolü ayrı bir işleve yerleştirerek (veya görünümleri kullanarak) kodu koda göre uygulayabilirsiniz.
• zarif silme. Silinen içerikle ilgilenen kullanıcılar veya işlemler, bir sonraki yenilemeye ulaşana kadar içeriği "görmeye" devam edecektir. Bir işlem aniden silinen bazı verileri işliyorsa bu çok istenen bir özelliktir.
• senkronizasyon: bir veritabanı ve mobil uygulamalar arasında bir senkronizasyon mekanizması tasarlamanız gerekiyorsa, yazılımdan silmelerin uygulanmasının çok daha kolay olduğunu göreceksiniz

Re: "Bu güvenli mi?" - bu ne demek istediğine bağlı.

Bunu fiziksel silme yaparak kastediyorsanız , silinen verileri herhangi birinin bulmasını engelleyeceksiniz , o zaman evet, bu aşağı yukarı doğru; Silinmesi gereken hassas verileri fiziksel olarak silmede daha güvendesiniz, çünkü bu, verilerin veritabanından kalıcı olarak gittiği anlamına gelir. (Ancak, söz konusu verilerin yedeklemede veya işlem günlüğünde olduğu gibi başka kopyalarının veya aktarım sırasında kaydedilmiş bir sürümün, örneğin bir paket dinleyicinin de olabileceğinin farkında olun - sırf veritabanınızdan sildiğiniz için başka bir yere kaydedilmediğini garanti eder.)

Mantıksal silme yaparak verilerinizin daha güvende olduğunu kastediyorsanız, hiçbir veriyi asla kaybetmeyeceksiniz , bu da doğru. Bu, denetim senaryoları için iyidir; Bu şekilde tasarlama eğilimindeyim, çünkü veri bir kez oluşturulduktan sonra asla gerçekten kaybolmayacağı gerçeğini kabul ediyor (özellikle de bir internet arama motoru tarafından önbelleğe alınma yeteneğine sahipse). Elbette gerçek bir denetim senaryosu, yalnızca silme işlemlerinin mantıklı olmasını değil, aynı zamanda değişiklik zamanı ve değişikliği yapan aktörle birlikte güncellemelerin de günlüğe kaydedilmesini gerektirir.

Verilerin, onu görmemesi gereken kimsenin eline geçmeyeceğini kastediyorsanız, bu tamamen sizin uygulamanıza ve güvenlik yapısına bağlıdır. Bu bakımdan mantıksal silme, veritabanınızdaki herhangi bir şeyden daha fazla veya daha az güvenli değildir.

Mantıksal silme işlemine kesinlikle katılmıyorum çünkü birçok hataya maruz kalıyorsunuz.

Öncelikle her sorgu IsDeleted alanına dikkat etmelidir ve karmaşık sorgularda hata olasılığı artar.

İkinci olarak performans: Sadece 3'ü etkin olan 100000 kayıt içeren bir tablo hayal edin, şimdi bu sayıyı veritabanınızın tabloları için çarpın; başka bir performans sorunu, yeni kayıtlarla eski (silinmiş kayıtlar) olası bir çakışmadır.

Gördüğüm tek avantaj kayıtların geçmişidir, ancak bu sonuca ulaşmak için başka yöntemler de vardır, örneğin bilgileri kaydedebileceğiniz bir günlük tablosu oluşturabilirsiniz: TableName,OldValues,NewValues,Date,User,[..]nerede *Valuesolabilir varcharve ayrıntıları bu forma yazabilirsiniz fieldname : value; [..] veya bilgileri olarak saklayın xml.

Tüm bunlar kod veya Tetikleyiciler aracılığıyla elde edilebilir, ancak tüm geçmişinize sahip yalnızca BİR tablodunuz . Diğer bir seçenek de, belirtilen veritabanı motorunun değişikliği izlemek için yerel destek olup olmadığını görmektir, örneğin SQL Server veritabanında SQL İzleme Verisi Değişikliği vardır.

Eskiden eski kayıtları tutmak için yumuşak silme yapardım. Kullanıcıların eski kayıtları düşündüğüm sıklıkta görüntülemeye zahmet etmediklerini fark ettim. Kullanıcılar eski kayıtları görmek isterlerse, sadece arşivden veya denetim tablosundan görüntüleyebilirler, değil mi? Peki, yazılımla silme işleminin avantajı nedir? Yalnızca daha karmaşık sorgu ifadesine vb. Yol açar.

Artık yazılımla silmemeye karar vermeden önce uyguladığım şeyler şunlardır:

1. Tüm etkinlikleri kaydetmek için denetim uygulayın (ekleme, düzenleme, silme). Denetime bağlı yabancı anahtar olmadığından emin olun ve bu tablonun güvenli olduğundan ve yöneticiler dışında kimsenin silemeyeceğinden emin olun.

2. Hangi tabloların "işlem tablosu" olarak kabul edildiğini, büyük olasılıkla uzun süre saklanacağını ve büyük olasılıkla kullanıcı geçmiş kayıtları veya raporları görüntülemek isteyebilir. Örneğin; satın alma işlemi. Bu tablo sadece ana tablonun kimliğini (bölüm kimliği gibi) değil, aynı zamanda referans olarak ad (bölüm adı gibi) veya raporlama için diğer gerekli alanlar gibi ek bilgileri de tutmalıdır.

3. Ana tablonun "etkin / etkin değil" veya "etkinleştir / devre dışı bırak" veya "gizle / göster" kaydını uygulayın. Böylece, kaydı silmek yerine, kullanıcı ana kaydı devre dışı bırakabilir / devre dışı bırakabilir. Böylesi çok daha güvenli.

Benim iki sentlik fikrim.

Bilgi tutarlılığı konusunda zorsa mantıksal silme işlemleri.

Tablo verilerinin geçici bir yönü olduğunda yapılacak doğru düşünce budur (FROM_DATE - TO_DATE için geçerlidir).

Aksi takdirde, verileri bir Denetim Tablosuna taşıyın ve kaydı silin.

Artı tarafta:

Geri almanın daha kolay yolu (mümkünse).

Zamanın belirli bir noktasında durumun ne olduğunu görmek kolaydır.

Bir şeyin geçmişini saklamak istediğiniz durumlarda oldukça standarttır (örneğin @ Jon Dewees'in bahsettiği kullanıcı hesapları). Kullanıcıların silme işlemlerinin kaldırılmasını istemesi için güçlü bir şans varsa, bu kesinlikle harika bir fikir.

Sorgularınızdan silinen kayıtları filtreleme mantığının dağınık hale gelmesinden ve yalnızca sorgularınızı karmaşıklaştırmasından endişe ediyorsanız, filtrelemeyi sizin için yapan görünümler oluşturabilir ve buna karşı sorguları kullanabilirsiniz. Raporlama çözümleri ve benzerlerinde bu kayıtların sızmasını önleyecektir.

Sistem tasarımının ötesinde yanıtlanması gereken gereksinimler vardır. Kayıt saklama konusundaki yasal veya yasal gereklilik nedir? Satırların neyle ilgili olduğuna bağlı olarak, verilerin 'askıya alındıktan' sonra belirli bir süre saklanması için yasal bir gereklilik olabilir.

Öte yandan, kayıt 'silindikten' sonra gerçekten ve geri alınamaz bir şekilde silinmesi şarttır. Karar vermeden önce paydaşlarınızla konuşun.

Senkronizasyona dayalı mobil uygulamalar, fiziksel silme yerine mantıksal silme kullanımını zorunlu kılabilir: bir sunucu, istemciye bir kaydın silindiğini (olarak işaretlendiğini) belirtebilmelidir ve kayıtlar fiziksel olarak silindiyse bu mümkün olmayabilir.

Veritabanının, basamaklama işlevi gibi şeyleri işe yaramaz hale getirmesi gerektiği gibi çalışmasına izin vermezler.

Eklemeler gibi basit şeyler için, yeniden ekleme durumunda, arkasındaki kod ikiye katlanır.

Sadece ekleyemezsiniz, bunun yerine bir varlığını kontrol etmeniz ve daha önce var olup olmadığını kontrol etmeniz veya varsa silme bayrağını güncellemeniz gerekirken diğer tüm sütunları yeni değerlere güncelleyebilirsiniz. Bu, veritabanı işlem günlüğünde bir güncelleme olarak görülür ve yanlış denetim günlüklerine neden olan yeni bir ekleme olarak görülmez.

Performans sorunlarına neden olurlar çünkü tablolar artık verilerle doludur. Özellikle benzersizliği ile indekslemede sorun yaratır.

Mantıksal silmelerin büyük bir hayranı değilim.

Tohid'in yorumuna cevap vermek için, kayıtların geçmişini sürdürmek istediğimizde aynı problemle karşılaştık ve ayrıca is_deletedsütun isteyip istemediğimizden emin değildik .

Python uygulamamızdan ve çarptığımız benzer bir kullanım durumundan bahsediyorum.

Karşılık gelen tablonuz için sürüm tablosunu almanın kolay bir yolu olan https://github.com/kvesteri/sqlalchemy-continuum ile karşılaştık . Minimum kod satırı ve ekleme, silme ve güncelleme için geçmişi yakalar.

Bu, is_deletedsütundan daha fazlasına hizmet eder . Bu girişe ne olduğunu kontrol etmek için her zaman sürüm tablosunu geri alabilirsiniz. Girişin silinmiş, güncellenmiş veya eklenmiş olup olmadığı.

Bu şekilde hiç is_deletedsütuna ihtiyacımız yoktu ve silme işlevimiz oldukça önemsizdi. Bu şekilde is_deleted=False, API'lerimizden herhangi birini işaretlemeyi de hatırlamamız gerekmez .

Yumuşak Silme, verilerin daha alakalı olduğu uygulamaların çoğunda takip edilen bir programlama uygulamasıdır. Son kullanıcının yanlışlıkla silmesinin ölümcül olabileceği bir finansal uygulama durumunu düşünün. Bu, yumuşak silme işleminin önemli hale geldiği durumdur. Yumuşak silmede kullanıcı, verileri kayıttan fiilen silmez, bunun yerine IsDeleted olarak true olarak işaretlenir (Normal kural gereği).

EF 6.x veya EF 7'den itibaren Softdelete bir öznitelik olarak eklenmiştir, ancak şimdilik özel bir öznitelik oluşturmamız gerekiyor.

SoftDelete'i bir veritabanı tasarımında şiddetle tavsiye ederim ve programlama uygulaması için iyi bir kuraldır.

Çoğu zaman yazılım silme kullanılır çünkü bazı verileri açığa çıkarmak istemezsiniz, ancak bunları tarihsel nedenlerle saklamanız gerekir (Bir ürün sona erebilir, bu nedenle onunla yeni bir işlem istemezsiniz ancak yine de çalışmanız gerekir. satış işleminin geçmişi). Bu arada, bazıları bunu işlemek için ürüne referans yapmak yerine satış işlem verilerindeki ürün bilgisi değerini kopyalıyor.

Aslında, görünür / gizli veya etkin / devre dışı bir özelliğin yeniden ifade edilmesi gibi görünüyor. Çünkü iş dünyasında "sil" in anlamı budur. Terminatörlerin insanları silebileceğini ama patronun onları kovduğunu söylemek isterim.

Bu uygulama oldukça yaygındır ve pek çok nedenle birçok uygulama tarafından kullanılmaktadır. Bunu başarmanın tek yolu bu olmadığından, binlerce insanın bunun harika ya da saçma olduğunu söyleyeceği ve her ikisinin de oldukça iyi argümanları olacak.

Güvenlik açısından, SoftDelete, Denetim işinin yerini almaz ve yedekleme işinin de yerini almaz. "İki yedekleme vakası arasında ekleme / silme" den korkuyorsanız, Tam veya Toplu kurtarma Modelleri hakkında bilgi almalısınız. SoftDelete'in kurtarma sürecini daha önemsiz hale getirebileceğini kabul ediyorum.

İhtiyaçlarınızı bilmek size kalmış.

Bir alternatif vermek için, MobiLink üzerinden güncelleme yapan uzak cihazları kullanan kullanıcılarımız var. Sunucu veritabanındaki kayıtları silersek, bu kayıtlar hiçbir zaman istemci veritabanlarında silinmiş olarak işaretlenmez.

Yani ikisini de yapıyoruz. Verileri ne kadar süreyle kurtarmak istediklerini belirlemek için müşterilerimizle birlikte çalışıyoruz. Örneğin, genellikle müşterilerimiz ve ürünler, müşterimiz silinmesi gerektiğini söyleyene kadar aktiftir, ancak satış geçmişi yalnızca 13 ay boyunca saklanır ve ardından otomatik olarak silinir. Müşteri, silinen müşterileri ve ürünleri iki ay boyunca saklamak, ancak geçmişi altı ay boyunca saklamak isteyebilir.

Bu nedenle, mantıksal olarak silinen şeyleri bu parametrelere göre işaretleyen bir komut dosyası çalıştırıyoruz ve ardından iki / altı ay sonra, bugün mantıksal olarak silinmiş olarak işaretlenen her şey kalıcı olarak silinecek.

Akıllı telefon gibi sınırlı belleğe sahip bir istemci cihazında muazzam veritabanlarına sahip olmaktan ziyade veri güvenliğiyle ilgileniyoruz. Dört yıl boyunca haftada iki kez 200 ürün sipariş eden bir müşteri, 81.000 satırlık geçmişe sahip olacak ve bunların% 75'i müşterinin görmesini önemsemeyecek.

Her şey sistemin kullanım durumuna ve verilerine bağlıdır.

Örneğin, hükümetin düzenlediği bir sistemden bahsediyorsanız (örneğin, bir ilaç firmasında kalite sisteminin bir parçası olarak kabul edilen ve elektronik kayıtlar için FDA yönergelerini takip etmesi gereken bir sistem), o halde zor silmeler yapmamak daha iyi olur! FDA'dan bir denetçi gelebilir ve ABC-123 ürün numarasıyla ilgili sistemdeki tüm kayıtları isteyebilir ve tüm verilerin mevcut olması daha iyi olur. İş süreci sahibiniz sistemin ileride yeni kayıtlarda ABC-123 ürün numarasını kullanmasına izin vermemesi gerektiğini söylüyorsa, geçmiş verileri korurken sistem içinde "devre dışı" hale getirmek için bunun yerine yazılımla silme yöntemini kullanın.

Ancak, belki sisteminizin ve verilerinin "Kuzey Kutbundaki hava durumunu izleme" gibi bir kullanım durumu olabilir. Belki saatte bir sıcaklık ölçümü yaparsınız ve günün sonunda günlük ortalama toplamı elde edersiniz. Belki saatlik veriler artık toplamadan sonra kullanılmayacaktır ve toplamı oluşturduktan sonra saatlik okumaları zor silersiniz. (Bu uydurma, önemsiz bir örnektir.)

Mesele şu ki, her şey sistemin ve verisinin kullanım durumuna bağlıdır ve tamamen teknolojik açıdan alınacak bir karara bağlı değildir.

İyi! Herkesin dediği gibi duruma göre değişir.

UserName veya EmailID gibi bir sütunda bir dizininiz varsa ve aynı UserName veya EmailID'nin bir daha kullanılmasını asla beklemiyorsanız; yumuşak bir silme ile gidebilirsiniz.

Bununla birlikte, SELECT işleminizin birincil anahtarı kullanıp kullanmadığını her zaman kontrol edin. SELECT deyiminiz birincil anahtar kullanıyorsa, WHERE yan tümcesi ile bir bayrak eklemek pek bir fark yaratmaz. Bir örnek alalım (Pseudo):

Tablo Kullanıcıları (Kullanıcı Kimliği [birincil anahtar], E-posta Kimliği, Silinmiş)

SELECT * FROM Users where UserID = 123456 and IsDeleted = 0

UserID sütununun birincil anahtarı olduğundan, bu sorgu performans açısından herhangi bir fark yaratmayacaktır. Başlangıçta, tabloyu PK'ye göre tarayacak ve ardından bir sonraki koşulu yürütecektir.

Yazılımla silme işleminin hiç işe yaramadığı durumlar:

Büyük ölçüde tüm web sitelerinde kaydolma, benzersiz kimliğiniz olarak E-posta Kimliği'ni alır. Çok iyi biliyoruz, bir E-posta Kimliği bir kez facebook, G + gibi bir web sitesinde kullanıldığında, başkaları tarafından kullanılamaz.

Kullanıcı profilini web sitesinden silmek istediği bir gün gelir. Şimdi, mantıksal bir silme işlemi yaparsanız, o kullanıcı bir daha asla kayıt olamaz. Ayrıca, aynı E-posta Kimliğini kullanarak tekrar kaydolmak, tüm geçmişi geri yüklemek anlamına gelmez. Herkes bilir, silme, silme demektir. Bu tür senaryolarda fiziksel bir silme yapmamız gerekir. Ancak hesabın tüm geçmişini korumak için, bu tür kayıtları her zaman arşiv tablolarında veya silinmiş tablolarda arşivlemeliyiz.

Evet, çok sayıda yabancı masamızın olduğu durumlarda, işlem yapmak oldukça zahmetlidir.

Ayrıca, yumuşak / mantıksal silme işlemlerinin tablo boyutunuzu, dolayısıyla dizin boyutunu artıracağını unutmayın.

Zaten başka bir gönderide cevapladım . Ancak cevabımın buradaki soruya daha uygun olduğunu düşünüyorum.

: Yumuşak silme Benim pratik bir çözüm, aşağıdaki sütunlu yeni bir tablo oluşturarak arşivleme original_id, table_name, payload, (ve isteğe bağlı bir birinci anahtar `kimlik).

original_idSilinen kaydın orijinal kimliği nerede , silinen kaydın table_name tablo adıdır ( "user"sizin durumunuzda), payloadsilinen kaydın tüm sütunlarından JSON ile dizgeleştirilmiş dizedir.

Ayrıca, original_idikinci veri alımı için sütunda bir dizin oluşturmanızı öneririm .

Bu şekilde veri arşivleme. Bu avantajlara sahip olacaksınız

• Geçmişteki tüm verileri takip edin
• Silinen kaydın tablo yapısından bağımsız olarak, herhangi bir tablodan kayıtları arşivlemek için tek bir yere sahip olun
• Orijinal tablodaki benzersiz dizin endişesi yok
• Orijinal tablodaki yabancı endeksi kontrol etme endişesi yok
• WHEREHer sorguda silmeyi kontrol etmek için başka madde yok

Burada zaten yumuşak silme işleminin pratikte neden iyi bir fikir olmadığını açıklayan bir tartışma var . Yumuşak silme, gelecekte kayıtların sayılması gibi bazı olası sorunları beraberinde getirir ...

Avantajlar, verilerin korunması / sürdürülmesidir. Bir dezavantaj, önemli miktarda yumuşak silme içeren tablolardan veri sorgulama veya alma sırasında performansta bir düşüş olacaktır. Bizim durumumuzda biz her ikisinin bir kombinasyonunu kullanın: Başkaları önceki cevaplar da belirttiğimiz gibi, biz soft-delete users/clients/customersörneğin, ve hard-deleteüzerinde items/products/merchandisearı keept gerekmez yinelenen kayıtları vardır tablolar.

Duruma göre değişir, aşağıdakileri göz önünde bulundurun:

Genellikle, bir kaydı "yazılımla silmeniz" gerekmez. Basit ve hızlı tutun. Örneğin, bir ürünü silme artık kullanılamadığından, ürünün uygulamanızın tamamında geçici olarak silinmediğini kontrol etmeniz gerekmez (sayı, ürün listesi, önerilen ürünler vb.).

Yine de, bir veri ambarı modelinde "yazılımla silme" seçeneğini düşünebilirsiniz. örneğin , silinmiş bir ürüne ait eski bir fişi görüntülüyorsunuz. *