Boole veritabanı alanında False değerini Null olarak depolamam gerekir mi?


20

Diyelim ki Usertablosunda boole alanı olan bir uygulamanız var Inactive.

Yanlış olanı null olarak depolamanın doğasında yanlış olan bir şey var mı? Eğer öyleyse aşağı tarafın ne olması gerektiğini açıklayabilir misiniz? Bunu birkaç ay önce biriyle tartıştım ve ikimiz de uygulama / veritabanı boyunca tutarlı bir şekilde yaptığınız sürece önemli olmaması gerektiğini kabul ettik. Son zamanlarda, tanıdığım biri "doğru" trueya falseda kullanılması gerektiğini vurguluyordu , ama bunun nedenini gerçekten açıklamadılar.


25
Wikipedia Null is a special marker used in Structured Query Language (SQL) to indicate that a data value does not exist in the database bu kabul edilen bilgeliktir ve başvurunuzda Null'un ne anlama geldiğini yeniden tanımlamamalısınız. Kodunuzla çalışan herkes için kafa karıştırıcı olacaktır.
PersonalNexus

10
Neden bunu yapmak istersin? Neden yalnızca null olmayan bir bit alanı kullanmıyorsunuz ve sorunu üç durumlu bir alanla karıştırmak yerine istediğiniz davranış buysa varsayılanı false olarak ayarlamıyorsunuz?
JohnFx

5
Bunun neden çok kötü bir fikir olduğuna dair gerçek dünya örneği: SELECT * FROM foo WHERE bar = FALSEbeklediğiniz sonuçları vermiyor.
Blrfl

2
Boole yerine varsayılan 0 olan bir int sütunu kullanmayı düşünün. Bu şekilde yeni koşullar ortaya çıkarsa (örneğin, 'bekleyen' bir durum), veritabanı yapısını değiştirmeniz gerekmez.
GrandmasterB

4
Ancak false değerini null olarak depolarsanız, FILE_NOT_FOUND'u nasıl saklayacaksınız ?! ( thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx )
Ed James

Yanıtlar:


50

Yanlış olanı null olarak depolamanın doğasında yanlış olan bir şey var mı?

Evet.

Eğer öyleyse aşağı tarafın ne olması gerektiğini açıklayabilir misiniz?

NULL, False ile aynı değildir.

Tanım olarak, NULL içeren karşılaştırmalar (ve mantık) NULL (False değil) değerlerini döndürmelidir. Ancak, SQL uygulamaları değişebilir.

True and NULL NULL (Yanlış değil).

True and NULL or False NULL (Yanlış değil).

http://en.wikipedia.org/wiki/Null_(SQL)#Three-valued_logic_.283VL.29

http://technet.microsoft.com/en-us/library/cc966426.aspx


3
NULL değerinin neden yokluğunu temsil eden değer olduğuna dair kısa açıklama.
maple_shaft

2
ilk geliştirme işimin ilk günü, bu soru /
yanıttaki

1
Bağlandığınız makalenin nullmantıkla alakasızsa (durumunda olduğu gibi whatever OR TRUEveya whatever AND FALSEhiçbir değerin whateverkoşulu değiştiremediği durumlarda) ifadenin bir değer döndürdüğünü söylediğini unutmayın . Bu bir optimizasyon değil; öyle mantık eserlerini değerli 3 nasıl . Bu ifadeleri döndürmek UNKNOWN/ almak NULLiçin ısrar eden DBMS temelde kırılmıştır.
cHao

1
@ S.Lott, ama yanlış yerine null depolamak biraz yer kazanmak ??
azerafati

2
@Bludream: Boolean'lar için, boş bir alan DBMS'ye bağlı olarak daha fazla yer kaplayabilir. (Yine de neredeyse tüm durumlarda ihmal edilebilir bir miktardır.) Bir boolean tek bir bitle temsil edilebilir ... ancak nullable boolean üç olası değere (doğru, yanlış ve null) sahiptir ve bu nedenle birden fazla bite ihtiyaç duyar.
cHao

15

Boole alanındaki boş değerlere izin vererek, amaçlanan ikili gösterimi (true / false), 'null' girdilerinizin belirsiz olduğu üç durumlu bir gösterime (true, false, null) dönüştürürsünüz. 'Null' değeri ne uygun şekilde 'doğru' ya da 'yanlış' değildir. Yanlış olmanız için temsilciliğinizi güçlendirmek için hangi nedeniniz var?

Böyle bir desene karar verseniz ve uygulamanız boyunca tutarlı bir şekilde yapsanız bile, bu uygun değildir. Bu örüntünün neden yerinde olduğu taze gözlerin net olmadığı veya daha büyük olasılıkla o örüntünün yanlışlıkla kırıldığı bir durumla sonuçlanacaksınız.


5

Başkalarının söyledikleri. 3 olası değer bir boole değeri değildir.

Ancak 3 değere meşru bir ihtiyaç duyabilirsiniz. (Doğru, yanlış, bilinmeyen) gibi. Bu durumda bile, ultra normalizasyona giriyorsanız, hiçbir boş değere izin vermeyeceksiniz. Bunun yerine, gerçek bir boole değerini 1'e 1 ilişkisi olan başka bir tabloda depolayacaksınız. Bir null değeri, fiziksel olarak depolanmış bir null değeriyle değil, bir sorguda "başarısız" dış birleşimiyle üretilebilir.


Boole sorumun alanı dışında bunu yapmak için null kullanırsanız gerçek yanlış bilinmeyen neden kötü olur? Sorumun ötesinde genellikle kaçınılması gereken boş değerler var mı? Neden?
Ominus

3
@Ominus: Eğer safkansanız, genellikle sıfırlardan kaçınılmalıdır. Kullanılmak istedikleri gibi kullanılırsa (sahte bir sahte olarak değil, "burada değer yoktur" gibi false), o zaman onların yeri vardır. Eğer olmasaydı, var olmazlardı. Alternatif, belirtildiği gibi, temelde sadece satırınızın birincil anahtarı ve tek bir boole (veya int veya varchar veya neyiniz) olan başka bir tabloya sahip olmaktır. Aksi takdirde geçersiz kılmak istediğiniz her alan için. İlişkisel olarak saf olsa da, çoğu amaç için çok kıvrıktır.
cHao

-3

bool?bir boolean tipi? Hayır Bu tiptedir boolean. Sıfırlanabilir bir boole değeri 3 değere sahip olabilir: true, false ve null. Kullanmak için ya da ihtiyacına bağlıdır. Boş kullanmanız gerekebileceğinin meşru bir nedeni olabilir, ancak ikili gibi kokan bir tür olabilir, ancak cevabı bilmiyorsunuzdur. Yukarıdaki örnekte,Nullable<T>Tboolbool?User.IsActivenet görünüyor. Kullanıcı etkin veya etkin değil. Bir sistem olarak, bir kullanıcının aktif olup olmadığını bilmek isteyebilir. 'Belki' olmamalıdır. Ancak bir özellik bayrağı gibi bir şey düşünün. Özellik açık mı? Cevaplar evet, hayır ya da emin olmayabilir. Yalnızca bayrak true olarak ayarlandığında düğmeyi gösteren bir iş kuralınız olabilir. Biri bool'un varsayılan olarak yanlış olduğunu iddia edebilir, bu yüzden neden nulllable bool oluşturmalı? Gereksinimi tersine çevirin: veri kaynağındaki tüm değerleri true olarak ayarlayacak mısınız?


2
bu yazıyı okumak oldukça zor (metnin duvarı). Sakıncası var düzenleyebilir daha iyi bir şekle ing?
gnat
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.