Oracle'da boş değer kullanmamanın nedeni?

Şirketimiz ortak bir proje için başka bir yazılım şirketi ile arayüz oluşturuyor ve belirli bir değerin gösterilmemesi gerekiyorsa, bir -5000 (keyfi nöbetçi değeri) geçmemiz gerektiği söylendi; Bunun nedeni, Oracle veritabanlarındaki hiçbir sayı sütununun (şimdi eski) Oracle dev. Bu şirket ayrıca kodlarının büyük çoğunluğunu VB6'da yazıyor (yavaş yavaş başka bir gün için başka bir konu olan VB.NET'e geçiyor ...). Saf meraktan dolayı, bu önerinin geçerli bir nedeni var mı? Yanımda kimse düşünemiyorum.

--- Düzenle

Geri bildiriminiz için teşekkürler. Aynı soruyu CodeProject.com ( bağlantı ) üzerinde sordum ve çok benzer geri bildirim aldım . Birinin bu uygulamayı haklı çıkarmaya başlayabileceği tek zaman yabancı anahtarlarla ilgilidir ve sistemin hiçbir yerinde yabancı anahtar kullanmadıklarını söyleyebilirim. Bu tespiti yapan geliştiricinin (o şirkette çalışıyordum) benden çok daha fazla deneyimi var, bu yüzden alay başlamadan önce bunun geçerli bir nedeni olmadığından emin olmak istedim.

Gerçekçi olarak, gereksinim çılgınca. Bununla birlikte, tüm büyük çılgın fikirler gibi, muhtemelen altta yatan mantığı anlamayan insanlar tarafından bağlamın dışına çıkarılan bir potansiyel mantıklılık külçesine dayanmaktadır.

Hiçbir NULLdeğere izin verilmeyecek şekilde bir veritabanı şeması tasarlamak mantıklı olabilir . Ancak bunu yaparsanız, gerekli olmayan her öğenin ebeveyne uygun bir yabancı anahtar başvurusu ile ayrı bir tabloya ayrıldığı normalleştirme düzeyini taahhüt edersiniz. Genellikle pratikte yapılmaz, ancak mantıklı olduğu durumlarda faydalar olabilir.

Hiçbir NULLdeğere izin verilmeyecek şekilde bir veritabanı şeması tasarlayacaksanız, bir şeyin bilinmediğini belirtmek için sihirli değerlere izin vermenize izin vermenin hiçbir anlamı yoktur. Bu, NULLdeğerlere izin veren tüm sorunları tanıtır ve her yerde tekrarlanması gereken sihirli değerleri kontrol etmek için ek kod ekler. Veritabanı tasarımından bağımsız olarak sihirli değerlerin aktarılmasını gerektiren bir API geliştirmek mantıklı değildir - kodunuzu sihirli değerleri kontrol etmek için zorlayacaksanız, deliliğin diğer sistemlere yayılmasına izin vermemelisiniz. .

NULL yerine sihirli bir değer kullanmanın Geçerli Nedeni yoktur . Bu, bu karışıklığı yaratan birinin düşünce süreci olabilir. Bunun gibi bir şey yazarlar:

 SELECT c1, c2 FROM t1 WHERE c3 < 30;

Bu, bekledikleri sonuçları döndürmediğinde, NULL içermediğini ve bunu yazması gerekeceğini fark ederler:

SELECT c1, c2 FROM t1 WHERE c3 < 30 OR c3 IS NULL;

Gelecekte bunu yazmak veya yazmak istemiyorlar, bu yüzden tüm NULLS -5000'i yapma çözümü buluyorlar. Sihirli bir şekilde orijinal sorgu NULL herhangi bir değişiklik yapmadan işler. Fark etmedikleri şey, şimdi bu değerleri dışlamak isteyen birinin bunu yazmak zorunda olduğudur:

SELECT c1, c2 FROM t1 WHERE c3 < 30 AND c3 <> -5000;

Veya bu değerleri istiyorlarsa ve daha yüksek bir aralıkta arıyorlarsa:

SELECT c1, c2 FROM t1 WHERE c3 > 40 OR c3 = -5000;

Ayrıca aşağıdakilerin artık anlamlı olmayacağının farkında olmayabilirler:

SELECT c1, c2 FROM t1 WHERE c3 IS NULL;

Bunun yerine bir kişi sihirli değeri hatırlamak zorundadır. Kullanılan her veri türü ile daha fazla sihirli değeri hatırlamak zorundalar, örneğin 1/1 // 1900, "Z", -5000. Ayrıca, sihir değeri verilerdeyken, alternatif sihir değerlerini de hatırlamaları gerekir.

Bu nedenle, belirli bir durum için, disk alanı, dizin boyutu, sorgu ayrıştırma, tutarlılık vb.

Bu tamamen delilik ve bunun bir gerekçesi yok. NULLbir değerin yokluğunu temsil etmek ve -5000 bonker gibi gerçek bir değeri kullanmak için yaratılmıştır.

Normalde bu kadar kısa bir cevap yazmam, ama soru dba.se'de en görünür olanlardan biri olmayı hak ediyor ve daha fazla cevap daha iyi.

Biraz olumlu olmaya ve null yerine keyfi bir değer kullanma ihtiyacını haklı çıkarmaya çalıştığımı düşündüm ve belki de kapalı bir veri madenciliği veri kümesi dışında (en azından bana) bunun geçerli bir nedeni yok gibi görünüyor. performansı ve sorguları iyileştirmek ve basitleştirmek için ve daha sonra yalnızca sayıların verileri eğrebilecek değerler olmadığı durumlarda. Bu bile dikkatle düşünülmelidir. Tüm gerçek dünya koşullarında null değerine değer vermek iyi bir uygulama değildir. Bu gerçekten doğru olmadığından arkadaşınızdan düşmanınıza DEĞİL DEĞİL sütun tanımı yapar.

Uygulamamızın bazı (hatta tümü) sütunlar için NULL değer kabul etmemesi gerektiğini söylemek çok farklı bir şeydir. Bu mantıklı ve iyi bir uygulamadır ve boş değerlere izin vermemenin iyi belgelenmiş faydaları vardır (örneğin anahtarlar ve dizinler ve istatistiksel hesaplamalar). Ancak null değerinin "yerinde oturmasına" değer atamak hiç de aynı değildir. Öncelikle hiç kullanılmayacak bir değer seçmeniz, bu değeri sıfırda yaptığınız gibi filtrelemeniz ve hesaplamalarda ve özetlerde kullanmamanızı ve dış veri feed'lerinden kaldırmamayı unutmayın. . Bu, en azından, gerçek bir değeri temsil etmek için bir null değeri kullanmak kadar kötüdür; bu, kendinize kaçındığınızı söylediğiniz şeydir, ancak değilsiniz.

Null'ların neden olduğu sorunların birçoğu anlaşıldıktan sonra ele alınabilir (daha iyi normalleştirme, fonksiyon tabanlı veya bitmap dizinleri veya basit bir NEREDEN x NULL DEĞİLDİR). Bazı büyük Telco'larda veya Amazon'da aylık performans toplantısında bazı DBA'ların, muazzam veri kümelerindeki sorguları biraz hızlandırmak için bu büyük planı özetlediğini düşünüyor musunuz? Ben değere açığım ... ". Yoksa zamanlarını, istenmeyen null'ları filtrelemek için daha iyi uygulama tasarımı ve verdikleri gerçek verilere göre sorgu optimizasyonu arasında ayırdıklarını mı düşünüyorsunuz ? Tamam, belki aylık bir toplantı biraz iyimser, ancak ne zaman gerçekleşirse, "null'leri daha iyi bir API için -5000 (veya her neyse) ile değiştirmenin" bir gündem maddesi olmadığından emin olabilirim.

Benim için eksik verileri kabul etmeyeceğimi söylemek iyi (bir yaş veya fiyat veya bölge kodu veya herhangi bir şey olmalı) ve hatta bazen bu sütun için söylenecek bir varsayılan değer varsa başka bir şey koymazsınız. Bir değeri null olarak ayırmak iyi değildir. İkinci ad alanlarını örnek olarak düşünün. Bazen ebeveynler tüm kutuları dolduramayacak kadar tembel oldukları için bunlar olmaz. Aramalarımızı iyileştirmek için verilerimize "hiçbiri" veya "eksik" veya "bilinmeyen" ekliyor muyuz? Hayır, çünkü isimlerini bu değerlere değiştiren garip insanlar olabilir ve bu nedenle verileri yazdırdığımızda, dahil edip etmememiz gerektiğini bilmiyoruz. Bu basit ama geniş kapsamlı bir örnektir. NULL hakkında bilgimiz var ve bununla başa çıkmak için öngörülebilir fonksiyonlara sahibiz. Bunu daha iyi kodlayamazsınız.

Hiçbir yanıt (veya NULL) giriş isteğinize geçerli bir yanıt değilse, uygulamada veya veritabanında buna izin vermeyin, eğer iyi bir yanıtsa, hem uygulamanızda hem de veritabanınızda izin vermeli ve geçerli bir yanıt olarak. Geçerli bir dizi yanıtın parçasıysa, veritabanınız bunu saklayacak şekilde tasarlanmalıdır. Sonuçta hey demeyin, sayı alanları çok sıkıcıdır, sayıları lekeler halinde saklar ve her sayıyı temsil etmek için vahşi hayvanların resimlerini kullanır, çünkü bu fındık (serin ama fındık). Ayrıca B harfini sevmediğimize karar vermiyoruz ve bazı zalim Susam Sokağı kabusu gibi bunu verilerimizde # ile değiştiriyoruz. B bir yanıt değilse, kullanıcıya "Hey, buraya B koyamazsınız" diyoruz. Öyleyse null'a neden farklı davranıyorsunuz?

Bu yüzden uygulama düzeyinde istemediğiniz null'lardan kaçının ve veritabanınızla onlarla ilgilenin.