Silme işlemi, çoğu veri yapısına eklemekten çok neden daha zordur?

Silme işleminin birçok (çoğu?) Veri yapısının yerleştirilmesinden çok daha zor olmasının nedeninin belirli bir nedeni olduğunu düşünebiliyor musunuz?

Hızlı örnek: bağlantılı listeler. Ekleme önemsiz olmakla birlikte, silme işleminin önemli ölçüde zorlaştıran birkaç özel durumu vardır. AVL ve Red-black gibi kendiliğinden dengelenen ikili arama ağaçları, ağrılı silme uygulamasının klasik örnekleridir.

Çoğu insanın düşündüğü gibi yapması gerektiğini söylemek isterim: Yapıcı olarak tanımlamak bizim için daha kolaydır, bu da kolay yerleştirmelere iyi gelir.

Bu sadece bir zihinsel durumdan daha fazlasıdır; Silme işleminin zor olmasının fiziksel (yani dijital) nedenleri vardır.

Sildiğinizde eskiden bir şeyin olduğu bir delik bırakırsınız. Ortaya çıkan entropinin teknik terimi "parçalanma" dır . Bağlantılı bir listede bu, kaldırılan düğümün etrafına "yama atmanızı" ve kullandığı belleği serbest bırakmanızı gerektirir. İkili ağaçlarda ağacın dengesizliğine neden olur. Bellek sistemlerinde, yeni atanan bloklar silme ile geride bırakılan bloklardan daha büyükse, belleğin bir süre kullanılmaz hale gelmesine neden olur.

Kısacası, yerleştirme daha kolaydır çünkü yerleştireceğiniz yeri seçebilirsiniz. Silme işlemi zordur, çünkü hangi öğenin silineceğini önceden tahmin edemezsiniz.

Neden silmek daha eklemek daha zor olma eğilimindedir? Veri yapıları silme işleminden ziyade ekleme ile tasarlanır ve haklı olarak yapılır.

Bunu göz önünde bulundurun - bir veri yapısından bir şeyi silmek için, ilk önce orada olması gerekir. Öyleyse önce onu eklemelisin, yani en çok senin eklemelerin kadar silme işlemine sahip olduğun anlamına geliyor. Bir veri yapısını ekleme için optimize ederseniz, silme için optimize edilmiş gibi en az fayda elde edeceğiniz garanti edilir.

Ek olarak, her bir öğeyi sırayla silmek için hangi kullanım var? Neden sadece hepsini bir anda temizleyen bir işlev çağırmıyorsunuz (sadece yeni bir tane oluşturarak)? Ayrıca, veri yapıları bir şey içerdiklerinde en faydalıdır. Öyleyse, eklemeler kadar fazla silme işlemi söz konusu olduğunda, pratikte pek yaygın olmayacak.

Bir şeyi optimize ettiğinizde, en çok ve en çok zaman alan şeyleri optimize etmek istersiniz. Normal kullanımda, bir veri yapısındaki öğelerin silinmesi ekleme işleminden daha az gerçekleşir.

Zor değil.

İki kat bağlantılı listelerde, taktığınızda, bellek tahsis edeceksiniz ve daha sonra baş veya önceki düğümle ve kuyruk veya sonraki düğümle bağlanacaksınız. Sildiğinizde, tamamen aynı olanlardan sonra bağlantıyı açacak ve ardından belleği boşaltıyor olacaksınız. Bütün bu işlemler simetriktir.

Bu, her iki durumda da eklemek / silmek için düğüme sahip olduğunuzu varsayar. (Ve ekleme durumunda, daha önce ekleyeceğiniz düğüme sahip olduğunuzdan, bir şekilde eklemenin biraz daha karmaşık olduğu düşünülebilir.) Silme düğümü değil, yükü silme girişiminde bulunmaya çalışıyorsanız Düğümden sonra, elbette önce yükü listelemek için listeyi aramanız gerekecek, fakat bu silinme sıkıntısı değil, değil mi?

Dengeli ağaçlarda, aynısı geçerlidir: Bir ağaç genellikle yerleştirmeden hemen sonra ve ayrıca silme işleminden hemen sonra dengelenmeye ihtiyaç duyar. Yalnızca bir dengeleme yordamını denemek ve sahip olmak ve bir ekleme mi yoksa silme mi olursa olsun, her işlemden sonra uygulamak iyi bir fikirdir. Ağacı her zaman dengeli bırakan bir ekleme ve aynı zamanda ağacı her zaman dengeli bırakan bir silme işlemi yapmaya çalışıyorsanız, ikisi aynı dengeleyici rutini paylaşmadan, hayatınızı gereksiz yere karmaşıklaştırıyorsunuz.

Kısacası, birinin diğerinden daha zor olmasının bir nedeni yoktur ve bunun olduğunu buluyorsanız, o zaman düşünmeyi daha doğal bulma eğiliminin (çok insani) eğiliminin mağduru olmanız mümkündür. Yapıcı olarak, çıkartıcı olarak, silme işlemini olması gerekenden daha karmaşık bir şekilde uyguladığınız anlamına gelir. Ama bu bir insan meselesi. Matematiksel bir bakış açısıyla, hiçbir sorun yoktur.

Çalışma zamanı açısından , Vikipedi'deki veri yapısı işlemlerinin zaman karmaşıklığı karşılaştırmasına bakıldığında, ekleme ve silme işlemlerinin aynı karmaşıklığa sahip olduğuna dikkat edin. Buradaki profil silme işlemi, silinecek yapı elemanına bir referansınızın bulunduğu, indekse göre silmedir; ekleme, öğeye göredir. Uygulamada silmek için daha uzun çalışma süresi, genellikle dizinini silmek için değil de bir öğeye sahip olmanızdır, bu nedenle bir bulma işlemine de ihtiyacınız vardır. Tablodaki çoğu veri yapısı, yerleştirme konumu öğeye bağlı olmadığından veya yerleştirme sırasında konum dolaylı olarak belirlendiğinden ek için bir ek bulma gerektirmez.

Bilişsel karmaşıklığa gelince, soruda bir cevap var: son vakalar. Silme işlemi, ekleme işleminden daha fazlasına sahip olabilir (bu, genel davada henüz kurulmamıştır). Bununla birlikte, bu kenar durumlarından en azından bazılarının belirli tasarımlarda önlenmesi sağlanabilir (örneğin, bağlı bir listede bir sentinel düğüme sahip).

Bahsi geçen tüm konuların üstünde, veri referans bütünlüğü söz konusudur. SQL'deki veritabanları gibi veri yapılarının en doğru şekilde oluşturulması için Oracle referans bütünlüğü çok önemlidir.
Yanlışlıkla icat etmediğinizden emin olmak için icat ettiği pek çok şeyi.
Örneğin, silme işleminde yalnızca silmeye çalıştığınız şeyi silmez, aynı zamanda ilgili verilerin temizliğini de tetikler.
Bu veritabanını önemsiz verilerden temizlemenin yanı sıra verilerin bütünlüğünü de korur.
Örneğin, ikinci tabloda ana babalara ve türlere ilişkin ilgili kayıtlar olarak tablolarınız var.
Ebeveyn ana masanın olduğu yer. Eğer yerinde sağlam bir referans bütünlüğü yoksa, herhangi bir tablodaki kayıtları silebilir ve daha sonra tam aile bilgilerinin nasıl alınacağını bilemezsiniz çünkü alt tablodaki verileriniz ve üst tabloda hiçbir şey yoktur.
Bu nedenle referans bütünlüğü denetimi, alt tablodaki kayıtlar temizlenene kadar ana tablodaki kaydı silmenize izin vermez.
Bu yüzden çoğu veri kaynağında verileri silmek daha zordur.