SQL: boş dize vs NULL değeri

Bu konunun biraz tartışmalı olduğunu biliyorum ve internette dolaşan birçok makale / görüş var. Maalesef çoğu, kişinin NULL ile boş dize arasındaki farkın ne olduğunu bilmediğini varsayıyor. Bu yüzden birleşme / toplanmalarla şaşırtıcı sonuçlar hakkında hikayeler anlatıyorlar ve genellikle biraz daha gelişmiş SQL dersleri veriyorlar. Bunu yaparak, tüm noktayı kesinlikle özlüyorlar ve bu yüzden benim için yararsızlar. Bu yüzden umarım bu soru ve tüm cevaplar konuyu biraz ileri götürecek.

Sanırım sütunlardan birinin varchar tipinde bir e-posta adresi olduğu kişisel bilgileri içeren bir masa (isim, doğum, vb.) Var. Bazı nedenlerden dolayı bazı kişilerin bir e-posta adresi vermek istemeyebileceğini varsayıyoruz. Bu tür verileri (e-posta olmadan) tabloya eklerken, iki seçenek vardır: hücreyi NULL olarak ayarlayın veya boş dizgeye ('') ayarlayın. Bir çözümden başka birini seçmenin tüm teknik etkilerinin farkında olduğumu ve her iki senaryoda da doğru SQL sorguları oluşturabileceğimi varsayalım. Sorun, her iki değer de teknik seviyede farklılık gösterse de, mantıksal seviyede tamamen aynıdır. NULL'a ve '' ye baktıktan sonra tek bir sonuca geldim: Adamın e-posta adresini bilmiyorum. Ayrıca ne kadar uğraştığım önemli değil. NULL veya boş dize kullanarak bir e-posta gönderemedim, bu yüzden görünen o ki çoğu SMTP sunucusu benim mantığımla aynı fikirde. Bu yüzden değeri bilmediğim ve boş dizgiyi kötü bir şey olarak gördüğümde NULL kullanma eğilimindeyim.

Meslektaşlarımla yapılan yoğun tartışmalardan sonra iki soru ile geldim:

1. bilinmeyen bir değer için boş dize kullanmanın bir veritabanının gerçekler hakkında "yalan söylemesine" neden olduğunu varsaymakta haklı mıyım? Daha kesin olmak gerekirse: SQL'in neyin değerli olup olmadığı hakkındaki fikrini kullanarak, şu sonuca varabilirim: e-posta adresimiz var, sadece null olmadığını öğrenerek. Ama daha sonra, e-posta göndermeye çalışırken çelişkili sonuca geleceğim: hayır, e-posta adresimiz yok, @! # $ Veritabanı yalan söylemiş olmalı!

2. Boş bir dizgenin '' önemli bir bilgiyi (değer ve değer hariç) iyi bir taşıyıcı olabileceği, başka bir şekilde (ek sütun gibi) saklamak zahmetli / verimsiz olabilecek mantıklı bir senaryo var mı? Bazen gerçek değerleri ve NULL'larla birlikte boş dize kullanmanın iyi olduğunu iddia eden birçok gönderi gördüm, ancak şimdiye kadar mantıklı olacak bir senaryo görmedim (SQL / DB tasarımı açısından).

Not: Bazı insanlar, sadece kişisel bir zevk meselesi olduğunu yanıtlamaya özendirilecektir. Katılmıyorum Bana göre önemli sonuçları olan bir tasarım kararıdır. Bu nedenle, bu konudaki fikirlerin bir takım mantıksal ve / veya teknik sebeplerle desteklendiği cevapları görmek istiyorum.

Bunun NULL"e-posta adresi yok" için doğru seçim olduğunu söyleyebilirim . Orada birçok "geçersiz" e-posta adresleri ve "" (boş dize) sadece bir tanesidir. Örneğin "foo" geçerli bir e-posta adresi değil, "a @ b @ c" geçerli değil. Bu nedenle, "" geçerli bir e-posta adresi olmadığı için, "e-posta adresi yok" değeri olarak kullanmanız için bir neden yoktur.

"" Bu sütun için bir değerim yok "demenin doğru yolu olmadığını söylemekte haklısınız. "" Olan bir değer.

Bir NULLkişinin göbek adı olabilirken , "" nin geçerli bir değer olabileceği bir örnek . Her birinin bir göbek adı yoktur, bu nedenle "göbek adı yok" ("" - boş dize) ve "Bu kişinin göbek adı olup olmadığını bilmiyorum" ( NULL) arasında ayrım yapmanız gerekir . Muhtemelen boş bir dize hala bir sütun için geçerli bir değer olduğu başka birçok örnek vardır.

Yukarıdaki yorumları kabul ederken, bu argümanı birincil bir motivasyon olarak ekleyeceğim:

1. Herhangi bir programcı için NULL işaretli bir alanın isteğe bağlı bir alan olduğu açıktır. (yani kayıt bu sütun için veri gerektirmiyor)
2. NULL DEĞİL bir alanı işaretlerseniz, herhangi bir programcı sezgisel olarak Zorunlu bir alan olduğunu varsaymalıdır.
3. Boş değerlere izin veren bir alanda, programcılar boş dizeler yerine boş değerler görmeyi beklemelidir.

Kendini Belgeleme Sezgisel Kodlama uğruna, boş dizeler yerine NULL kullanın.

Örneğinizde doğrudan web alanından değer ise - boş dize kullanırdım. Kullanıcı e-posta vermek istemediğini belirtebiliyorsa ya da silebiliyorsa - NULL.

İşte göz önünde bulundurabileceğiniz noktaların bağlantısı: https://stackoverflow.com/questions/405909/null-vs-empty-when-dealing-with-user-input/405945#405945

--- düzenlendi (Thomas yorumuna cevap olarak) ---

Veritabanları, onları kullanan uygulamalar olmadan yaşamaz. NULL veya '' tanımlaması, uygulama düzgün kullanamıyorsa değeri yoktur.

Kullanıcının LONG formunu doldurup enter tuşuna basıp, sunucuya kalıcı bir istek gönderecek bir örnek düşünün. E-postasını girmenin ortasında olabilir. Muhtemelen e-posta alanında ne varsa saklamak istersiniz, böylece daha sonra bitirebilir. Ya sadece bir karakter girerse? Ya bir karakter girip sonra onu silerse? E-posta gerekli olmadığında, bazen kullanıcılar silmek ister: alanı temizlemenin en kolay yolu. Ayrıca, e-posta gerekmediğinde, göndermeden önce onaylamanız gerekir.

Başka bir örnek: kullanıcı spamto @ [bigcompany] .com olarak e-posta sağlar - bu durumda e-posta gönderilmesine gerek yoktur, öyle olsa bile ve geçerli olabilir (ve hatta olabilir). Bu kadar ucuz bir tane gönderme, ancak günlük abonelikler için bu tür e-postalara sahip 10 bin kullanıcı varsa, o zaman bu doğrulama çok zaman kazandırabilir.

Bence Dean Hardings'in cevabı gerçekten çok hoş. Bu, DB seviyesindeki NULL'ler ve boş dizgiler hakkında konuşurken, diğer veri tipleriniz hakkında düşünmeniz gerektiğini belirtmek istediğimi söyledi. Tarih belirtilmediğinde minimum tarihi saklar mısınız? int verilmediğinde veya -1; Bir değeriniz olmadığında bir değerin kaydedilmesi, o zaman bir dizi değer içermemeyi izlemeniz gerektiği anlamına gelir. Her veri türü için en az bir tane (muhtemelen -1 değerinin gerçek olduğu durumlarda daha fazla seçenek buldukça daha fazla seçenek olabilir). Uygulama düzeyinde "hileli" bir şey yapmak istiyorsanız / istiyorsanız, bu bir şeydir, ancak verilerinizi kirletmeye gerek yoktur.

Ne yazık ki, Oracle, NULL'ın temsili ile VARCHAR'ın sıfır uzunluğundaki dizgesinin gösterimini karıştırdı. Her ikisi de dahili olarak sıfır değerine sahip tek bir bayt ile temsil edilir. Bu, tartışmayı daha da zorlaştırıyor.

NULL'u çevreleyen karmaşaların çoğu üç değerli mantığa odaklanıyor . Aşağıdaki sahte kodu göz önünde bulundurun:

if ZIPCODE = NULL
    print "ZIPCODE is NULL"
else if ZIPCODE <> NULL
    print "ZIPCODE is not NULL"
else print "Something unknown has happened"

Üçüncü mesajı beklemezsiniz, ancak üç değerli mantık altında elde edeceğiniz şey budur. Üç değerli mantık, insanları sayısız hataya yönlendirir.

Diğer bir karmaşa kaynağı, köpeklerin geceleri havlamayan bir çıkarımın çizilmesi gibi veri yokluğundan çıkarımlar çekmek. Genellikle bu çıkarımlar, NULL'un yazarının araştırmak istediği şey değildi.

Bunu söyledikten sonra, NULL'un veri yokluğunu iyi idare ettiği ve tam olarak istediğiniz sonuçları üreten birçok durum vardır. Bir örnek isteğe bağlı ilişkilerde yabancı anahtarlardır. Belirli bir satırda hiçbir ilişki olmadığını belirtmek için NULL kullanırsanız, bu satır beklediğiniz gibi iç birleşmeden ayrılır.

Ayrıca, NULLS'yi saklanan verilerde tamamen kaçınsanız bile (altıncı normal form), herhangi bir dış birleştirme yaparsanız, yine de NULLS ile baş etmek zorunda kalacağınızı unutmayın.

Null kullanın.

'' Değerinin kaydedilmesinin bir anlamı yoktur, sadece tablodaki alanı nullable yapacaktır. Sorguları da daha açık hale getirir.

Bir e-posta adresine sahip kullanıcıları bulmak istiyorsanız, hangi SQL sorgusu daha açık ve okunabilir?

1. SELECT * FROM Users WHERE email_address != ''

2. SELECT * FROM Users WHERE email_address IS NOT NULL

3. SELECT * FROM Users WHERE email_address != '' and email_address IS NOT NULL

2 olduğunu söyleyebilirim. Her ne kadar 3 saklı veri bulunmadığı durumlarda daha sağlamdır.

İsteğe bağlı olan formdaki e-posta adresleri için de tabloya yansıtılmalıdır. SQL'de, null olan bir alandır, yani bilinmediği anlamına gelir.

Boş bir dize, sadece kötü tasarım dışında bir tabloda bir depoda saklamak için makul bir iş değeri düşünemiyorum. 'NULL' veya 'BLANK' değerinin bir dizgesini saklamak gibi ve geliştiricilerin boş veya boş bir dizge olduğunu varsaymaları gibi. Bana göre bu kötü bir tasarım. NULL olduğunda neden saklıyorsun?

Sadece NULL kullanın, böylece herkesi biraz daha mutlu edersiniz.

DAHA FAZLA BİLGİ:

SQL, üç değerli bir mantık sistemi kullanır: Doğru, Yanlış ve Bilinmeyen.

Daha iyi ve daha ayrıntılı bir açıklama için geliştiricilerin okumasını öneririm: SQL Sorguları - DOĞRU ve YANLIŞ dışında .

Belirli bir teknik soru için, sorun boş değil dize boş değil, bir doğrulama hatası . Boş bir dize geçerli bir e-posta adresi değil!

felsefi soru için cevap benzerdir: girdilerinizi doğrulayın. Boş bir dize, söz konusu alan için geçerli bir değerse, onu bekleyin ve kodunu girin; değilse, null kullanın.

Boş bir dize soruyu cevaplamak için geçerli bir girdi olacaktır: Mime zürafaya ne dedi?

NULL ve boş dizgenin olmasının bir sebebini düşünebilirim:

• Geçerli bir e-posta adresin var: me@example.com
• Hiçbiriniz yok (ve muhtemelen bir tane sormalısınız): NULL
• Bu kişinin bir e-posta adresi olmadığını biliyorsunuz: Empty String.

Bununla birlikte, bunu önermeyeceğim ve mevcut olup olmadığını bilmediğinizi sorup sormamak için ayrı bir alan kullanmam.

Anladığım soru, NULL ve boş dize yorumlarının seçilmesi gerektiğidir. Bu kaç bağlıdır devletler particualar alan olabilir.

Yorum, veritabanına nasıl erişildiğine bağlıdır. Kodda veritabanını tamamen çıkaran bir katman varsa, çalışan herhangi bir politikayı (iki kural dahil) seçmek tamamen kabul edilebilir. (Yine de politikanın açıkça belgelenmesi önemlidir). Ancak, veritabanına birkaç yerde erişiliyorsa, o zaman kodun korunması zor olacağından ve bu durumda hatalı olabileceğinden çok basit bir şema kullanmalısınız.

Temelde mantıksal seviyede, "geçersiz" değer ile "kullanıcı girişi yok" arasında bir fark yoktur, hepsi çoğu zaman sadece "özel durumlar" dır. Hata durumu

Boş değere sahip olmak ayrıca boş alan alır: satır başına / bayt cinsinden ceil (column_with_null / 8).

Boş hücre ve null, bir şeyin yanlış olduğunu işaretlemenin bir yoludur / varsayılan olmalıdır. Neden 2 "yanlış" duruma ihtiyacın var? Neden ek yer kaplarlar ve tamamen boş dizelerle aynı anlama geliyorlarsa NULL'ları kullanın? Bu, aynı anlama gelen (yani aynı anlama gelebilecek) iki şeye sahip olduğunuzda, karışıklığı ve artıklığı getirecektir, boş dizeler yerine NULL kullanmanız gerektiğini (örneğin, kullanıcı bazı alanları atlattıysa) unutmak kolaydır.

Ve verileriniz karışıklığa neden olabilir. Mükemmel bir dünyada, “veriler daima doğru olacaktır ve hatırlayacağım” diyeceksiniz ... ama insanlar bir takımda çalışmak zorunda kaldıklarında ve herkes tam olarak sizin seviyenizde değilse, NEREDE görmek nadir değildir (aa. xx <> '' VE bb.zz NULL DEĞİLDİR)

Bu yüzden ekip üyelerimi her geçen gün düzeltmek yerine basit bir kuralı uyguladım. Boş değer yok, ASLA!

NULL-NON olmayan değerleri saymak daha hızlıdır ... basit soru, bunun için ne yapmanız gerekir?

DB perspektifinden değil, program perspektifinden görmeye meyilliyim. Bu sorunun SQL tıklaması için olduğunu biliyorum, ancak gerçekte, kaç kullanıcı doğrudan verilere erişiyor?

Bir programda null / hiçbir şey sevmiyorum. Birkaç istisna var, ama sadece bunlar. Ve bu istisnalar gerçekten sadece kötü uygulamalar.

Dolayısıyla, kullanıcı e-postaya girmediyse, bunun geçerli olup olmadığını belirleyen bir şey olmalıdır. Boş bir e-posta iyi ise boş bir dize görüntüler. Kullanıcı bir e-posta girmediyse ve bu bir kuralı ihlal ederse, nesne bunu belirtmelidir.

Boş değere sahip olmak fikri eski okul ve modern programcıların üzerinde çalışmak zorunda kaldıkları bir şey.

DB tasarımında bile e-posta alanı null değerine izin vermiyor ve sıfır uzunluklu bir dizeye sahip değil ve kullanıcının bir şey girip girmediğini belirten başka bir alana sahip olamaz? Bir DBMS istemek için bu kadar çok mu? DB bence ne iş mantığını ne de ekran mantığını işlememelidir. Bunun için inşa edilmedi ve bu nedenle kullanımı çok zayıf bir iş yapıyor.

Çok önemli olduğunu sanmıyorum, ama NULL olduğunda daha çok hoşuma gidiyor.

Bir tabloda görüntülenen verileri görüntülediğimde (SQL Server Management Studio'daki gibi), NULL yazıyorsa ve arka plan farklı renkte ise eksik bir değeri daha iyi ayırt edebilirim.

Boş bir alan görürsem, her zaman gerçekten boş olup olmadığını veya bazı boşluklar veya görünmeyen karakterler olup olmadığını merak ediyorum. NULL ile ilk görüşte boş garantilidir.

Genellikle uygulamadaki değerleri ayırt etmiyorum, çünkü beklenmedik ve NULL ve boş dizgelerin farklı bir şeyler ifade etmesi garip. Ve çoğu zaman savunmacı bir yaklaşım benimsem ve her iki devletle de ilgilenirim. Ancak benim için bir insan olarak NULL, verilere bakarken işlem yapmak daha kolay.