Veritabanındaki hatalı null girişlere karşı koruma sağlayan tasarımlar ve uygulamalar

Programımın bir kısmı, veritabanımdaki birçok tablo ve sütundaki verileri işlenmek üzere alıyor. Sütunlardan bazıları olabilir null, ancak geçerli işleme bağlamında bu bir hatadır.

Bu "teorik olarak" olmamalıdır, bu yüzden eğer kötü veriler veya koddaki bir hataya işaret eder. Hangi alanın olduğuna bağlı olarak hataların farklı önem dereceleri vardır null; yani bazı alanlar için işlem durdurulmalı ve birileri bilgilendirilmeli, bazıları için işlemenin devam etmesine ve birisini bilgilendirmesine izin verilmelidir.

Nadir fakat olası nullgirişleri ele alacak iyi bir mimari veya tasarım ilkesi var mı?

Çözümlerin Java ile uygulanması mümkün olmalı, ancak etiketi kullanmadım çünkü sorunun biraz dil bilincine sahip olmadığını düşünüyorum.

Kendime sahip olduğum bazı düşünceler:

NOT NULL kullanma

En kolay veritabanında NOT NULL kısıtlaması kullanmak olacaktır.

Peki ya verilerin orijinal olarak eklenmesi bu sonraki işlem adımından daha önemli ise? Bu yüzden eklenti nulltabloya bir hata koyarsa (hatalar veya belki de geçerli bir sebepten dolayı), ekin başarısız olmasını istemem. Programın daha birçok bölümünün eklenen verilere bağlı olduğunu ancak bu sütuna bağlı olmadığını varsayalım. Bu nedenle, ekleme adımı yerine geçerli işlem adımında hata riskini tercih ederim. Bu yüzden NOT NULL kısıtlaması kullanmak istemiyorum.

Saf olarak NullPointerException özelliğine bağlı

Verileri her zaman orada olmasını beklediğim gibi kullanabilirim (ve bu gerçekten böyle olmalı) ve ortaya çıkan NPE'leri uygun bir seviyede yakalayabilirim (örneğin, mevcut girişin işlenmesi durur, ancak tüm işleme ilerlemesi değil) ). Bu "hızlı başarısız" ilkesi ve ben sık sık tercih ederim. En azından bir hata ise, kayıtlı bir NPE alırım.

Ama sonra çeşitli eksik veri türlerini ayırt etme yeteneğini kaybediyorum. Örneğin, bazı eksik veriler için veriyi dışarıda bırakabilirim, ancak diğerleri için işlem durdurulmalı ve bir yönetici bilgilendirilmelidir.

nullHer erişimden önce kontrol etme ve özel istisnalar atma

Özel istisnalar, istisnayı temel alarak doğru eyleme karar vermeme izin verecek, bu yüzden bu yol gibi görünüyor.

Ama bir yerde kontrol etmeyi unutursam ne olur? Ayrıca daha sonra asla veya nadiren beklenen null çekler ile kod dağınıklığı (ve kesinlikle iş mantık akışının bir parçası değil).

Bu şekilde gitmeyi seçersem, yaklaşım için hangi modeller en uygunudur?

Yaklaşımlarım ile ilgili her türlü düşünce ve yorumlarınızı bekliyoruz. Ayrıca her türlü daha iyi çözümler (kalıplar, ilkeler, kodumun daha iyi mimarisi veya modelleri vb.).

Düzenle:

Başka bir kısıtlama var, ben bir ORM DB kalıcılık nesnesine eşleme yapmak için kullanıyorum, bu nedenle bu düzeyde null kontrolleri yapmak işe yaramaz (null herhangi bir zarar vermediği yerlerde aynı nesneler kullanılır gibi) . Bunu ekledim çünkü şimdiye kadar verilen cevaplar bu seçenekten bahsetti.

Nesnenizi sonuç kümesinden oluşturduğunuz eşleme kodunuza null kontrolleri koyacağım. Bu, denetimi tek bir yere koyar ve bir hataya çarpmadan önce kodunuzun bir kaydı işleyerek yarıya inmesine izin vermez. Uygulama akışınızın nasıl çalıştığına bağlı olarak, her bir kaydın tek tek eşlenmesi ve işlenmesi yerine tüm sonuçların eşlenmesini bir ön işleme adımı olarak gerçekleştirmek isteyebilirsiniz.

Bir ORM kullanıyorsanız, her kaydı işlemeden önce tüm boş denetimlerinizi yapmanız gerekir. Ben recordIsValid(recordData)-type yöntemi tavsiye ederim , bu şekilde (tekrar) tüm null kontrol ve diğer doğrulama mantığını tek bir yerde tutabilirsiniz. Boş kontrolleri işleme mantığınızın geri kalanıyla kesinlikle karıştırmam.

Bir boş değer eklemek hata gibi görünüyor, ancak veri kaybetmek istemediğiniz için bu hatayı ekleme işleminde uygulamaktan korkuyorsunuz. Ancak, bir alan boş olmamalı, ancak boşsa veri kaybediyorsunuzdur . Bu nedenle, en iyi çözüm null alanların yanlışlıkla kaydedilmemesini sağlamaktır.

Bu amaçla, söz konusu veri, veritabanı için bir yetkili, kalıcı depoda verilerin doğru olmasını sağlayın. Boş olmayan kısıtlamalar ekleyerek bunu yapın. Daha sonra kodunuz başarısız olabilir, ancak bu hatalar sizi hemen hatalardan haberdar ederek, veri kaybetmenize neden olan sorunları düzeltmenizi sağlar. Artık hataları kolayca belirleyebildiğinize göre, kodunuzu ve iki kez test edebilirsiniz . Veri kaybına yol açan hataları düzeltebileceksiniz ve bu süreçte, verilerin aşağıya doğru işlenmesini büyük ölçüde basitleştireceksiniz, çünkü null'lar için endişelenmenize gerek kalmayacak.

Sorudaki bu cümle ile ilgili olarak:

Bu "teorik olarak" olmamalıdır, bu yüzden eğer kötü veriler veya koddaki bir hataya işaret eder.

Bu alıntıyı her zaman takdir ettim ( bu makalenin izniyle ):

Acemi programcılar ana işlerinin programların çökmesini önlediğine inandıklarında eğlenceli buluyorum. Bu muhteşem başarısızlık argümanının böyle bir programcıya bu kadar çekici gelmeyeceğini düşünüyorum. Daha deneyimli programcılar doğru kodun harika olduğunu, çökmelerin kodunu iyileştirmeyi kullanabileceğini, ancak çökmeyen yanlış kodların korkunç bir kabus olduğunu fark ederler.

Temel olarak: Postel Yasasını onaylıyormuşsunuz gibi geliyor , "gönderdiğiniz şeyde muhafazakar olun, kabul ettiğiniz şeyde liberal olun". Teoride büyük olmakla birlikte, pratikte bu "sağlamlık ilkesi" en azından uzun vadede ve bazen de kısa vadede sağlam olmayan yazılıma yol açmaktadır . ( Çoğunlukla ağ protokolü kullanım vakalarına odaklanmış olsa da, konunun çok kapsamlı bir tedavisi olan Sağlamlık İlkesi Yeniden Düşünülen makalesini karşılaştırın .)

Veritabanınıza yanlış veri ekleyen programlarınız varsa, bu programlar bozuktur ve düzeltilmesi gerekir . Sorun üzerinde kağıtlama sadece daha da kötüleşmeye devam etmesini sağlar; bu, bir bağımlıya bağımlılığını devam ettirme olanağı sağlayan yazılım mühendisliği eşdeğeridir .

Pragmatik olarak konuşmak gerekirse, bazen "kırık" davranışın en azından geçici olarak, özellikle gevşek, kırık bir durumdan katı, doğru bir duruma sorunsuz bir geçişin bir parçası olarak devam etmesini sağlamanız gerekir. Bu durumda, yanlış eklemelerin başarılı olmasına ve "kurallı" veri deposunun her zaman doğru durumda olmasına izin vermenin bir yolunu bulmak istersiniz . Bunu yapmanın çeşitli yolları vardır:

• Hatalı oluşturulmuş ekleri doğru eklere dönüştürmek için bir veritabanı tetikleyicisi kullanın, örneğin eksik / boş değerleri varsayılanlarla değiştirerek
• Yanlış programların "yanlış" olmasına izin verilen ayrı bir veritabanı tablosuna eklenmesini sağlayın ve düzeltilmiş verileri bu tablodan standart veri deposuna taşıyan ayrı bir zamanlanmış işleme veya başka bir mekanizmaya sahip olun.
• Veritabanından alınan verilerin, beklemedeki veriler olmasa bile her zaman doğru durumda olduğundan emin olmak için sorgu tarafı filtrelemesi (örn. Bir görünüm) kullanın

Tüm bu sorunları ortadan kaldırmanın bir yolu, yazma sorunları ve gerçek veritabanı arasında kontrol ettiğiniz bir API katmanı eklemektir.

Sorununuzun bir parçası gibi görünüyor, yanlış yazma oluşturan tüm yerleri bile bilmiyorsunuz - ya da güncellemeniz için çok fazla şey var. İçinde olmak korkunç bir durum, ama ilk etapta ortaya çıkmasına asla izin verilmemeliydi.

Kanonik bir üretim veri deposundaki verileri değiştirmesine izin verilen birkaç sistemden daha fazlasını alır almaz başınız derde girer: bu veritabanı hakkında merkezi bir şey tutmanın hiçbir yolu yoktur . Daha iyisi, yazma işlemlerini mümkün olduğunca az sayıda işleme izin vermek ve bunları gerekli şekilde eklemeden önce verileri önceden işleyebilen "ağ geçidi denetçileri" olarak kullanmaktır. Bunun kesin mekanizması gerçekten sizin mimarinize bağlıdır.

" Nadir ama olası null girdileri ele almak için iyi mimari veya tasarım ilkeleri var mı? "

Basit cevap - evet.

ETL

Verilerin veritabanına girmek için yeterli kalitede olmasını sağlamak için bazı ön işlemleri gerçekleştirin. Bırakma dosyasındaki her şey geri bildirilmeli ve tüm temiz veriler veritabanına yüklenebilir.

Hem kaçak avcı (dev) hem de oyun kaleci (DBA) olan biri olarak, acı deneyimlerden, 3. tarafların zorlanmadıkça veri sorunlarını çözmeyeceğini biliyorum. Sürekli geriye doğru eğilme ve verilere masaj yapma tehlikeli bir emsal oluşturur.

Mart / Depo

Bu senaryoda, ham veriler depo DB'sine aktarılır ve daha sonra sanitize edilmiş bir sürüm, uygulamaların erişebileceği mart DB'ye aktarılır.

Varsayılan değerler

Sütunlara varsayılan varsayılan değerleri uygulayabiliyorsanız, bu, varolan bir veritabanı ise, bazı işleri içerebilir.

Erken başarısız

Sadece uygulama, rapor paketi, arayüz vb. Ağ geçidindeki veri sorunlarını ele almak caziptir. Sadece buna güvenmemenizi şiddetle tavsiye ederim. DB'ye başka bir widget'ı bağlarsanız, muhtemelen aynı sorunlarla tekrar karşılaşırsınız. Veri kalitesi sorunlarını giderin.

Kullanım durumunuz NULL değerini güvenli bir şekilde iyi bir varsayılan değerle değiştirmeye izin verdiğinde, dönüştürmeyi SELECTSql deyimlerinde ISNULLveya kullanarak yapabilirsiniz COALESCE. Yani yerine

 SELECT MyColumn FROM MyTable

biri yazabilir

 SELECT ISNULL(MyColumn,DefaultValueForMyColumn) FROM MyTable

Tabii ki, bu sadece ORM doğrudan select deyimlerini doğrudan değiştirmeye izin verirse veya nesil için değiştirilebilir şablonlar sağlarsa işe yarar. Bu şekilde hiçbir "gerçek" hatanın maskelenmediğinden emin olunmalıdır, bu yüzden yalnızca NULL durumunda varsayılan değerle değiştirmek tam olarak istediğiniz şeyse uygulayın.

Veritabanını ve şemayı değiştirebiliyorsanız ve db sisteminiz bunu destekliyorsa, @RobbieDee tarafından önerilen şekilde belirli sütunlara varsayılan bir değer cümlesi eklemeyi düşünebilirsiniz. Bununla birlikte, bu, daha önce girilen NULL değerleri kaldırmak için veritabanındaki mevcut verilerin de değiştirilmesini gerektirir ve daha sonra doğru ve eksik içe aktarma verilerini ayırt etme yeteneğini ortadan kaldırır.

Kendi tecrübelerime göre, ISNULL kullanmanın şaşırtıcı derecede iyi çalışabileceğini biliyorum - geçmişte orijinal geliştiricilerin çok sayıda sütuna NOT NULL kısıtlamaları eklemeyi unuttuğu eski bir uygulamayı sürdürmek zorunda kaldım ve bu kısıtlamaları daha sonra kolayca ekleyemedik bazı nedenlerden dolayı. Ancak tüm vakaların% 99'unda, sayı sütunları için varsayılan olarak 0 ve metin sütunları için varsayılan olarak boş dize tamamen kabul edilebilirdi.

OP, iş kurallarını veritabanı teknik detayları ile birleştiren bir cevap varsaymaktadır.

Bu "teorik olarak" olmamalıdır, bu yüzden eğer kötü veriler veya koddaki bir hataya işaret eder. Hangi alanın boş olduğuna bağlı olarak hataların farklı önem dereceleri vardır; yani bazı alanlar için işlem durdurulmalı ve birileri bilgilendirilmeli, bazıları için işlemenin devam etmesine ve birisini bilgilendirmesine izin verilmelidir.

Tüm iş kuralları bu. İş kuralları null per se umurumda değil. Her şey için veritabanı null, 9999, "BOO!" ... sadece başka bir değer. Bir RDBMS'de, null'un ilginç özellikleri vardır ve benzersiz kullanımları tartışmalıdır.

Önemli olan tek şey, "işsizliğin" verilen iş nesneleri için ne anlama geldiğidir ...

Nadir ama olası null girdileri ele almak için iyi bir mimari veya tasarım ilkesi var mı?

Evet.

• İş kurallarını sınıflara koyun.
• Harf çevirisi, iş sınıflarını ve veri deposunu ayıran uygun bir kod katmanında olmalıdır. ORM koduna koyamazsanız en azından veritabanına koymayın.
• Veritabanını olabildiğince aptal hale getirin, burada iş kuralları yok. Bir değeri varsayılan etmek gibi zararsız şeyler bile sizi ısıracaktır . Orada bulunmak.
• Veritabanına giden ve veritabanından gelen verileri doğrulayın. Ve elbette bu, iş nesneleri bağlamında yapılır.

Veri alımı üzerine bir istisna atmak mantıklı değildir.

Soru "kötü" verileri saklamalı mıyım? " Değişir:

• Hatalı veriler kullanılabilir - Asla geçersiz nesneleri veya nesne kompozitlerini kaydetmeyin. Her yerde karmaşık veri / iş ilişkileri. Kullanıcılar, istedikleri zaman herhangi bir işlevi yerine getirebilir, muhtemelen bu ticari varlığı bir dizi bağlamda kullanabilirler. Kötü verilerin, kaydedildiği andaki etkisi (eğer varsa), gelecekteki kullanıma büyük ölçüde bağımlı olduğu için bilinmemektedir. Bu verilerin birleştirilmiş / tek bir işlemi yoktur.
• Kötü veri varsa ilerleme kaydedilemez - Kötü verilerin kaydedilmesine izin ver. Ancak, bir süreçteki bir sonraki adım her şey geçerli olana kadar devam edemez. Örneğin gelir vergisi yapmak. Veritabanından alındığında yazılım hataları gösterir ve geçerlilik kontrolü yapılmadan IRS'ye gönderilemez.

Boş değerleri işlemenin birçok yolu vardır, bu nedenle veritabanı katmanından uygulama katmanına geçeceğiz.

Veritabanı katmanı

Sen edebilirsiniz boş değerlere korusun ; burada olmasına rağmen pratik değildir.

Sen edebilirsiniz varsayılan yapılandırmak başına kolon bazında:

• sütunun olmaması gerekir insert, bu nedenle açık null yerleştirmeyi kapsamaz
• insertbu sütunu yanlışlıkla kaçırdığı satırlardan algılamayı önler

Sen edebilir bir tetikleyici yapılandırmak sokulması üzerine kayıp değerleri otomatik olarak hesaplanır böylece,:

• bu hesaplamayı gerçekleştirmek için gerekli bilgilerin mevcut olmasını gerektirir
• yavaşlayacak insert

Sorgu katmanı

Sen edebilirsiniz satırları atlamak uygunsuz bir yerde nullbulunur:

• ana mantığı basitleştirir
• "kötü satırların" algılanmasını önler, bu nedenle bunları kontrol etmek için başka bir işlem gerekir
• her bir sorgunun araçsal olarak kullanılmasını gerektirir

Sen edebilirsiniz varsayılan bir değer sağlamak sorguda:

• ana mantığı basitleştirir
• "kötü satırların" algılanmasını önler, bu nedenle bunları kontrol etmek için başka bir işlem gerekir
• her bir sorgunun araçsal olarak kullanılmasını gerektirir

Not: Her bir sorguyu kullanmak, bunları oluşturmanın otomatik bir yoluna sahip olmanız şart değildir.

Uygulama katmanı

Tabloda yasak olup olmadığını önceden kontrol edebilirsiniz null:

• ana mantığı basitleştirir
• arıza süresini iyileştirir
• ön kontrol ve uygulama mantığının tutarlı olmasını gerektirir

Şunları yapabilirsiniz işlemi yarıda bir yasak karşılaştığında null:

• hangi sütunların nullhangilerinin olabileceğini bilmiyor
• hala nispeten basit (sadece bir çek + iade / atış)
• işleminizin devam ettirilmesini gerektirir (zaten bir e-posta gönderdiyseniz, iki kez veya yüz kez göndermek istemezsiniz!)

Şunları yapabilirsiniz satır atlama bir yasak karşılaştığında null:

• hangi sütunların nullhangilerinin olabileceğini bilmiyor
• hala nispeten basit (sadece bir çek + iade / atış)
• işleminizin devam etmesini gerektirmez

Şunları yapabilirsiniz Bir bildirim göndermek yasak bir karşılaştığında nullya bir seferde ya da başka yollar yukarıda sunulan ücretsiz olan toplu, tek. Bununla birlikte, en önemli olan "o zaman ne olur?", En önemlisi, satırın yamalanmasını ve yeniden işlenmeye ihtiyaç duymanız durumunda, önceden işlenmiş satırları ihtiyacı olan satırlardan ayırmanın bir yoluna sahip olduğunuzdan emin olmanız gerekebilir. yeniden işleniyor.

Durumunuz göz önüne alındığında, uygulamadaki durumu ele alıp aşağıdakilerden birini birleştiririm:

• kes ve bildir
• atla ve bildir

Özellikle işlem zaman alabilirse, bir şekilde bir miktar ilerlemeyi garanti etmek için mümkünse atlamaya eğilimliydim .

Atlanan satırları yeniden işlemeniz gerekmiyorsa, bunları günlüğe kaydetmenin yeterli olması gerekir ve işlem sonunda atlanan satır sayısı ile gönderilen bir e-posta uygun bir bildirim olacaktır.

Aksi takdirde, satırların düzeltilmesi (ve yeniden işlenmesi) için bir yan tablo kullanırdım. Bu yan tablo ya basit bir başvuru (yabancı anahtar olmadan) ya da tam bir kopya olabilir: ikincisi, daha pahalı olsa bile null, ana verileri temizlemek zorunda kalmadan önce adresleme zamanınız yoksa gereklidir .

Null'ler, veritabanı türlerinin dil türlerine çevrilmesinde veya eşlenmesinde kullanılabilir. Örneğin C # 'da, işte size herhangi bir tür için null işleyen genel bir yöntem:

public static T Convert<T>(object obj)
        {
            if (obj == DBNull.Value)
            {
                return default(T);
            }

            return (T) obj;
        }

public static T Convert<T>(object obj, T defaultValue)
        {
            if (obj == DBNull.Value)
            {
                T t = defaultValue;
                return t;
            }

            return (T) obj;
        }

Veya eylem gerçekleştirmek istiyorsanız ...

 public static T Convert<T>(object obj, T defaultValue)
        {
            if (obj == DBNull.Value)
            {
                //Send an Alert, we might want pass in the name
                //of column or other details as well
                SendNullAlert();
                //Set it to default so we can keep processing
                T t = defaultValue;
                return t;
            }

            return (T) obj;
        }

Ve sonra eşlemede, bu durumda "Örnek" türünde bir nesneye, sütunlardan herhangi biri için null değerini işleyeceğiz:

public class SampleMapper : MapperBase<Sample>
    {
        private const string Id = "Id";
        private const string Name = "Name";
        private const string DataValue = "DataValue";
        private const string Created = "Created";

        protected override Sample Map(IDataRecord record)
        {
            return new Sample(
                Utility.Convert<Int64>(record[Id]),
                Utility.Convert<String>(record[Name]),
                Utility.Convert<Int32>(record[DataValue]),
                Utility.Convert<DateTime>(record[Created])
                );
        }
    }

Son olarak, tüm harita sınıfları SQL sorgularına veya SQL veri türlerine bakarak ve dile özgü veri türlerine çevrilerek tablolara göre otomatik olarak oluşturulabilir. Birçok ORM'nin sizin için otomatik olarak yaptığı budur. Bazı veritabanı türlerinin doğrudan bir eşlemesi olmayabilir (Coğrafi konumsal sütunlar vb.) Ve özel işlem gerektirebilir.