SQL: खाली स्ट्रिंग बनाम NULL मान


72

मुझे पता है कि यह विषय थोड़ा विवादास्पद है और बहुत सारे लेख / राय इंटरनेट पर तैर रहे हैं। Unfortunatelly, उनमें से ज्यादातर मानते हैं कि व्यक्ति को पता नहीं है कि NULL और खाली स्ट्रिंग में क्या अंतर है। इसलिए वे जॉइन / एग्रीगेट के साथ आश्चर्यजनक परिणामों के बारे में बताते हैं और आम तौर पर थोड़ा और अधिक उन्नत एसक्यूएल पाठ करते हैं। ऐसा करने से, वे पूरी बात याद करते हैं और इसलिए मेरे लिए बेकार हैं। इसलिए उम्मीद है कि यह सवाल और सभी जवाब थोड़ा आगे बढ़ेंगे।

मान लें कि मेरे पास व्यक्तिगत जानकारी (नाम, जन्म आदि) के साथ एक तालिका है, जिसमें से एक स्तंभ, varchar प्रकार के साथ एक ईमेल पता है। हम मानते हैं कि किसी कारण से कुछ लोग ईमेल पता प्रदान नहीं करना चाहते हैं। ऐसे डेटा को (ईमेल के बिना) तालिका में सम्मिलित करते समय, दो उपलब्ध विकल्प होते हैं: सेल को NULL पर सेट करें या इसे रिक्त स्ट्रिंग ('') पर सेट करें। मान लेते हैं कि मुझे एक समाधान को दूसरे पर चुनने के सभी तकनीकी निहितार्थों के बारे में पता है और मैं किसी भी परिदृश्य के लिए सही SQL क्वेरी बना सकता हूं। समस्या तब भी है जब दोनों मूल्य तकनीकी स्तर पर भिन्न हैं, वे तार्किक स्तर पर बिल्कुल समान हैं। NULL और '' '' को देखने के बाद मैं एक निष्कर्ष पर पहुंचा: मुझे उस आदमी का ईमेल पता नहीं है। कोई फर्क नहीं पड़ता कि मैंने कितनी कोशिश की, मैं NULL या खाली स्ट्रिंग का उपयोग करके एक ई-मेल भेजने में सक्षम नहीं था, इसलिए जाहिरा तौर पर अधिकांश एसएमटीपी सर्वर मेरे तर्क से सहमत थे। इसलिए मैं NULL का उपयोग करता हूं जहां मुझे मूल्य का पता नहीं है और खाली स्ट्रिंग को एक बुरी चीज मानता है।

सहकर्मियों के साथ कुछ गहन चर्चाओं के बाद मैं दो सवालों के साथ आया:

  1. क्या मैं यह मानने में सही हूं कि किसी अज्ञात मान के लिए खाली स्ट्रिंग का उपयोग करने से तथ्यों के बारे में डेटाबेस "झूठ" हो रहा है? अधिक सटीक होना: एसक्यूएल के विचार का उपयोग करना कि मूल्य क्या है और क्या नहीं है, मैं निष्कर्ष पर आ सकता हूं: हमारे पास ई-मेल पता है, बस यह पता लगाकर कि यह शून्य नहीं है। लेकिन फिर बाद में, जब मैं ई-मेल भेजने की कोशिश कर रहा हूं तो मैं विरोधाभासी निष्कर्ष पर पहुंचूंगा: नहीं, हमारे पास ई-मेल पता नहीं है, कि @! # $ डेटाबेस झूठ बोल रहा होगा!

  2. क्या कोई तार्किक परिदृश्य है जिसमें एक खाली स्ट्रिंग '' महत्वपूर्ण जानकारी (मूल्य और मूल्य के अलावा) का इतना अच्छा वाहक हो सकता है, जो किसी अन्य तरीके से (अतिरिक्त स्तंभ की तरह) स्टोर करने के लिए परेशानी / अक्षम होगा। मैंने कई पोस्टों में दावा किया है कि कभी-कभी वास्तविक मान और NULLs के साथ खाली स्ट्रिंग का उपयोग करना अच्छा होता है, लेकिन अभी तक ऐसा परिदृश्य नहीं देखा गया है जो तार्किक (SQL / DB डिजाइन के संदर्भ में) होगा।

पुनश्च कुछ लोगों को जवाब देने के लिए परीक्षा होगी, कि यह सिर्फ व्यक्तिगत स्वाद की बात है। मैं सहमत नहीं हूँ। मेरे लिए यह महत्वपूर्ण परिणामों के साथ एक डिजाइन निर्णय है। इसलिए मैं उन उत्तरों को देखना चाहता हूं जहां इस बारे में कुछ तार्किक और / या तकनीकी कारणों से समर्थन प्राप्त होता है।


11
आप जानते हैं कि Oracle में, खाली स्ट्रिंग हैं है शून्य?
user281377

8
@ स्तनो: शून्य लंबाई के तार का ओरेकल उपचार अमानक है। इसके अलावा, ''ओरेकल में भी, के रूप में ही नहीं है NULL। उदाहरण के लिए, किसी CHAR(1)कॉलम को मान देने ''से परिणाम ' '(यानी एक स्थान) होगा, नहीं NULL। इसके अलावा, अगर जेसेक ओरेकल का उपयोग कर रहा था, तो यह प्रश्न संभवतः सामने नहीं आएगा :-)
डीन हार्डिंग

2
डीन: आप चार (1) उदाहरण के बारे में सही हैं, लेकिन पीएल / एसक्यूएल के '' IS NULLमूल्यांकन के बाद से यह अभी तक एक और डब्ल्यूटीएफ है true
user281377

"क्या मैं यह मानने में सही हूं कि अज्ञात मूल्य के लिए खाली स्ट्रिंग का उपयोग करने से डेटाबेस" तथ्यों के बारे में "झूठ" पैदा कर रहा है? यदि आपके व्यावसायिक उपयोगकर्ता अज्ञात बनाम खाली की परवाह नहीं करते हैं, तो क्या झूठ भी मायने रखता है?
एंडी

यदि आपको स्ट्रिंग का उपयोग करने का मार्ग जाना चाहिए ... कृपया, कृपया, सुनिश्चित करें कि यह खाली है। सभी डेवलपर्स के लिए, इसमें एक स्ट्रिंग न दें जिसमें एक स्थान हो जो आपके अज्ञात मूल्य का प्रतिनिधित्व करता हो। मैं तुमसे हाथ जोड़ कर प्रार्थना करता हूं।
Airn5475

जवाबों:


83

मैं कहूंगा कि NULL"नो ईमेल एड्रेस" के लिए यह सही विकल्प है। रहे हैं कई "अवैध" ईमेल पते, और "" (रिक्त स्ट्रिंग) से एक है। उदाहरण के लिए "foo" एक वैध ईमेल पता नहीं है, "a @ b @ c" मान्य नहीं है और इसी तरह। तो सिर्फ इसलिए कि "" एक वैध ईमेल पता नहीं है, इसका उपयोग "नो ईमेल एड्रेस" मान के रूप में करने का कोई कारण नहीं है।

मुझे लगता है कि आप यह कहने में सही हैं कि "" मेरे पास इस कॉलम के लिए मान नहीं है "" कहने का सही तरीका नहीं है। "" है एक मूल्य।

एक उदाहरण जहां "" एक वैध मान NULLहो सकता है, एक व्यक्ति के मध्य नाम के लिए अलग हो सकता है। हर एक का मध्य नाम नहीं है, इसलिए आपको "कोई मध्य नाम" ("" - खाली स्ट्रिंग) और "मुझे नहीं पता कि इस व्यक्ति का मध्य नाम है या नहीं" ( NULL) के बीच अंतर करने की आवश्यकता है । संभवतः कई अन्य उदाहरण हैं जहां एक स्तंभ के लिए एक खाली स्ट्रिंग अभी भी एक वैध मूल्य है।


5
पूर्णतया सहमत। NULL एक कारण के लिए है। चयन करें CO * (*) जहां से आपका ईमेल आता है वहां [नहीं] ऐसा करने का तरीका है, न कि स्ट्रिंग तुलना जो धीमी हो जाएगी (यहां तक ​​कि खाली तारों के लिए मुझे लगता है लेकिन मैं इस एक के बारे में सुनिश्चित नहीं हूं :)।
लुडोएमसी

5
मुझे लगता NULLहै कि इसका मतलब यह नहीं है कि कोई ईमेल पता नहीं है, मुझे लगता है कि इसका मतलब है कि ईमेल पता वर्तमान में ज्ञात नहीं है, मौजूद नहीं है, या अन्य कारणों से भरना असंभव है। सौभाग्य से, शायद कोई स्थिति नहीं है जहां कोई डेटाबेस में उन लोगों के बारे में जानकारी रखना चाहेगा जिनके पास वास्तव में नहीं है और किसी भी ईमेल पते की योजना नहीं है, अन्यथा एक अलग बूलियन फ़ील्ड संभवतः आवश्यक होगा।
एलेक्सी

9
@Alexey - NULL का मतलब कोई मूल्य नहीं है। जैसा कि दूसरों ने बताया है कि एक रिक्त स्ट्रिंग एक मान है।
रामहाउंड

3
@ रामहुड, मैं मानता हूँ कि खाली स्ट्रिंग एक मूल्य है, और यह कि पूर्ण अस्पष्टता का अर्थ है "कोई मूल्य नहीं है"। मैंने बस "कोई मूल्य नहीं" की मेरी व्याख्या की। मेरी राय में, यह "व्यक्ति ने कोई ईमेल खाता नहीं खोला है" जैसा नहीं है। बल्कि यह "उस व्यक्ति के लिए कोई ईमेल पता दर्ज नहीं है"।
एलेक्सी

5
@ रामहाउंड नाल का मतलब कोई मूल्य नहीं है। बिना मध्य नाम वाले व्यक्ति का कोई मूल्य नहीं है। इसलिए, NULL का उपयोग मध्य प्रारंभिक कॉलम में भी किया जाना चाहिए ... जो इस उत्तर में प्रस्तुत तर्क से पूरी तरह विपरीत है।
इज़काता

41

उपरोक्त टिप्पणियों से सहमत होते हुए, मैं इस तर्क को एक प्राथमिक प्रेरणा के रूप में जोड़ूंगा:

  1. यह किसी भी प्रोग्रामर को डेटाबेस को देखकर स्पष्ट है कि NULL के रूप में चिह्नित फ़ील्ड एक वैकल्पिक फ़ील्ड है। (अर्थात रिकॉर्ड के लिए उस कॉलम के डेटा की आवश्यकता नहीं है)
  2. यदि आप किसी फ़ील्ड को NULL से चिह्नित नहीं करते हैं, तो किसी भी प्रोग्रामर को सहज रूप से यह मान लेना चाहिए कि यह एक आवश्यक फ़ील्ड है।
  3. एक क्षेत्र में जो नल की अनुमति देता है, प्रोग्रामर को खाली तारों के बजाय नल देखने की अपेक्षा करनी चाहिए।

सेल्फ-डॉक्यूमेंटिंग इंसुवेटिंग कोडिंग के लिए, खाली स्ट्रिंग्स के बजाय NULL का उपयोग करें।


4
+1 यह "कम से कम विस्मय" तर्क है, जो खाली तारों के खिलाफ डेवलपर्स के संबंध में है। बाद में आने वाला कोई भी डेवलपर कभी यह उम्मीद नहीं करेगा कि "कोई ईमेल पता नहीं" का प्रतिनिधित्व करने के लिए खाली तारों का उपयोग किया जाएगा।
थॉमस

6

आपके उदाहरण में अगर यह सीधे वेब क्षेत्र से मूल्य है - मैं खाली स्ट्रिंग का उपयोग करूंगा। यदि उपयोगकर्ता यह निर्दिष्ट करने के लिए विकल्प दे सकता है कि वह ईमेल प्रदान नहीं करना चाहता है, या उसे हटा सकता है - तो NULL।

यहां उन बिंदुओं के लिंक दिए गए हैं, जिन पर आप विचार कर सकते हैं: https://stackoverflow.com/questions/405909/null-vs-empty-when-dealing-with-user-input/405945#405945

--- संपादित (थॉमस टिप्पणी के जवाब में) ---

डेटाबेस उन अनुप्रयोगों के बिना नहीं रहते जो उनका उपयोग करते हैं। NULL या '' को परिभाषित करने का कोई मूल्य नहीं है, यदि एप्लिकेशन इसका ठीक से उपयोग नहीं कर सकता है।

उपयोगकर्ता एक उदाहरण पर विचार करें जहां उपयोगकर्ता LONG फ़ॉर्म भर रहा है और एंटर दबाएं, जो सर्वर को लगातार अनुरोध भेजेगा। वह अपने ईमेल में प्रवेश करने के बीच में हो सकता है। सबसे अधिक शायद आप ईमेल क्षेत्र में जो कुछ भी है उसे स्टोर करना चाहते हैं, इसलिए बाद में वह इसे समाप्त कर सकता है। क्या होगा अगर वह केवल एक चरित्र में प्रवेश करे? क्या होगा अगर वह एक चरित्र में प्रवेश करे और फिर उसे हटा दे? जब ईमेल की आवश्यकता नहीं होती है, तो कभी-कभी उपयोगकर्ता इसे हटाना चाहते हैं: सिर्फ स्पष्ट क्षेत्र का सबसे आसान तरीका। इसके अलावा, जब ईमेल की आवश्यकता नहीं है, तो भेजने से पहले इसे मान्य करने के लायक है।

एक और उदाहरण: उपयोगकर्ता ईमेल को स्पैम्टो @ [bigcompany] .com के रूप में प्रदान करता है - उस स्थिति में ईमेल भेजने की कोई आवश्यकता नहीं है, यहां तक ​​कि यह मौजूद है और मान्य है (और मौजूद भी हो सकता है)। इस तरह के एक को भेजना शायद सस्ता है, लेकिन अगर दैनिक सदस्यता के लिए इस तरह के ईमेल के साथ 10K उपयोगकर्ता हैं, तो इस तरह के सत्यापन से बहुत समय बचाया जा सकता है।


7
-1। डेटाबेस एक वेबसाइट चला रहा है या नहीं अप्रासंगिक है। डेटाबेस डिजाइनिंग वेब डिजाइन की तुलना में अलग दुनिया है। डेटाबेस को लिखने के लिए उपयोग किए जाने वाले इंटरफ़ेस से स्वतंत्र व्यापार डोमेन के बारे में तथ्यों को पकड़ने के लिए डिज़ाइन किया जाना चाहिए। अपने तर्क से, क्या आपको नल का उपयोग करना चाहिए अगर संयोग से पहला आवेदन एक निष्पादन योग्य है? अगर पहला ऐप एक वेब एप्लिकेशन है तो क्या होगा लेकिन अगला एप्लिकेशन एक मोबाइल ऐप है? सामान्यीकरण नियमों का उपयोग करके तथ्यों को पकड़ने के लिए डेटाबेस डिज़ाइन करें और इसे लिखने के लिए वेब साइट डिज़ाइन करें।
थॉमस

मुझे खुशी है कि आपने इस साइट पर लिखना और टिप्पणी करना सीख लिया :) मुझे अभी भी विश्वास है कि DB को उस एप्लिकेशन का समर्थन करना चाहिए जो इसका उपयोग करता है। मेरे संपादित उत्तर की जाँच करें।
कॉन्स्टेंटिन पेट्रूख्नोव

4
डेटाबेस उन अनुप्रयोगों के बिना नहीं रहते जो उनका उपयोग करते हैं। मेरे अनुभव में, यह केवल सच और अदूरदर्शी नहीं है। लगभग हमेशा डेटाबेस उस एप्लिकेशन के बाहर उपयोग किया जाता है जिसके लिए इसे डिज़ाइन किया गया था। सामान्य तौर पर, डेटाबेस उन अनुप्रयोगों की तुलना में अधिक समय तक जीवित रहते हैं जिनके लिए उनका निर्माण किया गया था। डेटाबेस को व्यवसाय के बारे में तथ्यों को इकट्ठा करने के लिए डिज़ाइन किया जाना चाहिए और यूआई को डेटाबेस को पढ़ने और लिखने के लिए बनाया जाना चाहिए न कि दूसरे तरीके से। रिलेशनल डिज़ाइन एप्लिकेशन डिज़ाइन की तुलना में पूरी तरह से अलग मानसिकता है।
थॉमस

2
उदाहरण जहां डेटाबेस का उपयोग केवल मूल एप्लिकेशन द्वारा नहीं किया जाता है : रिपोर्ट, अन्य प्रणालियों के साथ एकीकरण।
थॉमस

1
जैसा कि थॉमस ने डीबी को इंगित किया है और अक्सर एक से अधिक एप्लिकेशन द्वारा उपयोग किया जाता है जो आपके डीबी डेटा को साफ रखने के विचार में वजन जोड़ता है। यदि आप अपने आवेदन में NULL को नहीं चाहते / संभाल नहीं सकते हैं, तो आप बस उन्हें अपने डेटा एक्सेस लेयर पर अपने "जादुई मूल्यों" (अच्छा विवरण थॉमस) के लिए स्थानापन्न कर सकते हैं। इस तरह से भविष्य के किसी भी एप्लिकेशन जो डीबी तक पहुंचना चाहते हैं, उन्हें मूल एप्लिकेशन मैजिक वैल्यू के बारे में जानने की जरूरत नहीं है।
बेंडेमेज़

5

मुझे लगता है कि डीन हार्डिंग्स का उत्तर वास्तव में अच्छी तरह से कवर करता है। मैंने कहा कि मैं इस बात का उल्लेख करना चाहूंगा कि जब डीबी स्तर पर रिक्त बनाम रिक्त तारों के बारे में बात की जाती है, तो आपको अपने अन्य डेटा प्रकारों के बारे में सोचना चाहिए। क्या कोई तारीख नहीं होने पर आप मिनिमम स्टोर करेंगे? या -1 जब कोई आपूर्ति नहीं की जाती है? एक मूल्य संग्रहीत करना जब आपके पास कोई मूल्य नहीं होता है तो इसका मतलब है कि आपको गैर-मूल्यों की एक पूरी श्रृंखला का ध्यान रखना होगा। प्रत्येक डेटा प्रकार के लिए कम से कम एक (संभवतः अधिक के रूप में आपको ऐसे मामले मिलते हैं जहां -1 वास्तविक मूल्य है इसलिए आपको कुछ वैकल्पिक आदि की आवश्यकता है)। यदि आपको आवेदन स्तर पर कुछ "फजी" करने की आवश्यकता है, जो एक बात है, लेकिन उन्हें आपके डेटा को प्रदूषित करने की कोई आवश्यकता नहीं है।


2
+1 - इसे मैं "मैजिक वैल्यू सॉल्यूशन" कहता हूं। हमें प्रत्येक डेटा प्रकार के लिए एक मूल्य की अनुपस्थिति का प्रतिनिधित्व करने के लिए एक जादुई मूल्य के साथ आना होगा। इसके अलावा, कुछ स्तंभों में सामान्य जादू मूल्य एक वैध मूल्य है या इस प्रकार एक नए जादू मूल्य की आवश्यकता है।
थॉमस

5

दुर्भाग्य से, Oracle ने NULL के प्रतिनिधित्व के साथ लंबाई शून्य के VARCHAR स्ट्रिंग के प्रतिनिधित्व को भ्रमित किया। वे दोनों मूल्य शून्य के साथ आंतरिक रूप से एक बाइट का प्रतिनिधित्व करते हैं। यह चर्चा को और अधिक कठिन बना देता है।

तीन-मूल्यवान तर्क के आसपास NULL केंद्रों को लेकर बहुत भ्रम है । निम्नलिखित छद्मकोश पर विचार करें:

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

आपको तीसरे संदेश की उम्मीद नहीं होगी, लेकिन तीन मूल्यवान तर्क के तहत आपको यही मिलेगा। तीन मूल्यवान तर्क लोगों को कई बगों की ओर ले जाते हैं।

भ्रम का एक अन्य स्रोत डेटा की अनुपस्थिति से निष्कर्ष निकालना है, जैसे कि कुत्ते से एक निष्कर्ष निकालना जो रात में छाल नहीं करता था। अक्सर ये इनिशियल्स वो नहीं थे जो NULL के लेखक ने cnvey के लिए किए थे।

यह कहने के बाद कि, ऐसी बहुत सी स्थितियाँ हैं जहाँ NULL डेटा की अनुपस्थिति को ठीक तरह से संभालता है, और आपके द्वारा इच्छित परिणाम तैयार करता है। एक उदाहरण वैकल्पिक रिश्तों में विदेशी कुंजी है। यदि आप किसी दिए गए पंक्ति में कोई संबंध नहीं इंगित करने के लिए NULL का उपयोग करते हैं, तो वह पंक्ति एक आंतरिक जॉइन से बाहर हो जाएगी, जैसा कि आप अपेक्षा करेंगे।

इसके अलावा, इस बात से अवगत रहें कि भले ही आप NULLS को संग्रहीत डेटा (छठे सामान्य रूप) से पूरी तरह से बचाते हैं, यदि आप कोई बाहरी जुड़ाव करते हैं, तो भी आपको NULLS से सामना करना पड़ेगा।


4

नल का उपयोग करें।

'' '' के मान को संचय करने का कोई मतलब नहीं है, जब बस तालिका में क्षेत्र को अशक्त बना देगा। यह प्रश्नों को और अधिक स्पष्ट करता है।

यदि आप ईमेल पते वाले उपयोगकर्ताओं को खोजना चाहते हैं, तो कौन सी SQL क्वेरी अधिक स्पष्ट और पठनीय है?

  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 है। यद्यपि 3 उन मामलों में अधिक मजबूत है जहां खराब डेटा संग्रहीत है।

प्रपत्र पर ईमेल पते के मामले के लिए, जो वैकल्पिक है, इसे तालिका में भी प्रतिबिंबित किया जाना चाहिए। SQL में, यह एक अशक्त क्षेत्र है, जिसका अर्थ है कि यह ज्ञात नहीं है।

मैं केवल खराब डिज़ाइन के अलावा एक खाली स्ट्रिंग को एक तालिका में संग्रहीत करने में किसी भी उचित व्यवसाय मूल्य के बारे में नहीं सोच सकता। यह 'NULL' या 'BLANK' के स्ट्रिंग मान को संग्रहीत करने जैसा है, और डेवलपर्स यह मानते हैं कि यह रिक्त या रिक्त स्ट्रिंग है। मेरे लिए, यह बुरा डिजाइन है। जब NULL हो तो क्यों स्टोर करें ??

बस NULL का उपयोग करें, और आप सभी को थोड़ा और खुश करेंगे।

और जानकारी:

SQL एक तीन मूल्यवान लॉजिक सिस्टम का उपयोग करता है: ट्रू, फाल्स और अनजान।

बेहतर और विस्तृत विवरण के लिए, मैं डेवलपर्स को पढ़ने की सलाह देता हूं: SQL क्वेरी - TRUE और FALSE से परे


3

विशिष्ट तकनीकी प्रश्न के लिए, मुद्दा शून्य बनाम रिक्त-स्ट्रिंग नहीं है, यह एक सत्यापन विफलता है । खाली स्ट्रिंग मान्य ईमेल पता नहीं है!

दार्शनिक प्रश्न के लिए, उत्तर समान है: अपने इनपुट को मान्य करें। यदि कोई रिक्त स्ट्रिंग प्रश्न में फ़ील्ड के लिए एक मान्य मान है, तो यह अपेक्षा करें और इसके लिए कोड करें; यदि नहीं, तो अशक्त का उपयोग करें।

एक खाली स्ट्रिंग सवाल का जवाब देने के लिए एक वैध इनपुट होगा: माइम ने जिराफ को क्या कहा?


यहां तक ​​कि दुनिया में सबसे अच्छे इरादे के साथ, सत्यापन इस समस्या को हल नहीं कर सकता है - उसे अभी भी पंक्तियों से निपटने के लिए एक विधि का उपयोग करना पड़ सकता है जहां सभी स्तंभों को किसी प्रकार के मूल्य के साथ आपूर्ति की जानी चाहिए। उस स्थिति में, यह सवाल बना रहेगा - जब कोई मूल्य नहीं है तो क्या उपयोग करना है? और उत्तर निश्चित रूप से होगा: वह मूल्य जो कोई मूल्य नहीं दर्शाता है। DBs में यह आमतौर पर NULL होता है।
जोर्मेनो

2

मैं NULL और खाली स्ट्रिंग होने के एक कारण के बारे में सोच सकता था:

  • आपके पास मान्य ईमेल पते हैं: me@example.com
  • आपके पास कोई नहीं है (और शायद एक के लिए पूछना चाहिए): NULL
  • आप जानते हैं कि इस व्यक्ति का ईमेल पता नहीं है: Empty String.

हालाँकि, मैं यह सलाह नहीं दूंगा कि किसी अलग क्षेत्र का उपयोग करें या नहीं, यह पूछने के लिए कि क्या आप जानते हैं कि कोई भी मौजूद नहीं है।


1

जैसा कि मैंने इसे समझा है, सवाल यह है कि NULL और खाली स्ट्रिंग की कौन-सी व्याख्याएँ चुनी जानी चाहिए। यह इस बात पर निर्भर करता है कि पार्टिकलर फील्ड कितने राज्यों में हो सकता है।

व्याख्या इस बात पर निर्भर करती है कि डेटाबेस तक कैसे पहुँचा जा रहा है। यदि कोड में एक परत है जो किसी भी नीति (दो-युग्मन सहित) को चुनने की तुलना में पूरी तरह से डेटाबेस को सार करती है, तो यह काम पूरी तरह से स्वीकार्य है। (स्पष्ट रूप से पॉलिसी का दस्तावेजीकरण करना महत्वपूर्ण है, हालांकि)। हालाँकि, यदि डेटाबेस को कई स्थानों पर एक्सेस किया जा रहा है, तो आपको एक बहुत ही सरल योजना का उपयोग करना चाहिए, क्योंकि कोड बनाए रखना कठिन होगा और इस मामले में गलत हो सकता है।


1

मूल रूप से तार्किक स्तर पर मूल रूप से "अमान्य" मान और "कोई उपयोगकर्ता इनपुट" के बीच कोई अंतर नहीं है, वे ज्यादातर सभी "विशेष मामले" हैं। त्रुटि का मामला।

शून्य होने से एडिटोनल स्पेस मिलता है: बाइट्स / प्रति पंक्ति में सीइल (कॉलम_विथ_नुल / 8)।

खाली सेल और अशक्त दोनों को चिह्नित करने का तरीका गलत है / डिफ़ॉल्ट होना चाहिए। आपको 2 "गलत" राज्यों की आवश्यकता क्यों होगी? यदि वे अतिरिक्त स्थान लेते हैं और रिक्त तारों के समान ही मतलब रखते हैं तो NULLs का उपयोग क्यों करें? जब आप दो चीजों का अर्थ निकाल रहे हैं, तो यह केवल भ्रम और अतिरेक का परिचय देगा (इसका मतलब यह हो सकता है) कि यह एक ही है, यह भूल जाना आसान है कि आपको खाली तारों के बजाय NULLs का उपयोग करना चाहिए (यदि उदाहरण के लिए। उपयोगकर्ता कुछ क्षेत्रों को छोड़ दिया है)।

और आपका डेटा गड़बड़ हो सकता है। एक आदर्श दुनिया में आप कहेंगे "डेटा हमेशा सही रहेगा और मुझे याद रहेगा" ... लेकिन जब लोगों को एक टीम में काम करना होता है और हर कोई आपके स्तर पर नहीं होता है तो WHERE (आ) देखना असामान्य नहीं है। xx <> '' और bb.zz नहीं है)

इसलिए हर दूसरे दिन मैं अपनी टीम के सदस्यों को सुधारने के बजाय सिर्फ सरल नियम लागू करता हूं। कोई शून्य मान, कभी नहीं!

NON-NULL मानों की गिनती तेज है ... सरल प्रश्न यह है कि आपको इसके लिए क्या करना होगा?


मैं कहीं न कहीं यह पढ़कर याद करता हूं कि डेटाबेस के लिए NULL का उपयोग वास्तव में एक लागत (अभिकलन और भंडारण दोनों) के लिए है। तो उस सूत्र को ऊपर लाने में अच्छी बात है।
जेस्क प्रुकिया

यह मत भूलो कि एक VARCHARतार स्ट्रिंग की लंबाई को स्टोर करने के लिए कम से कम 1 बाइट लेगा, भले ही यह शून्य हो।
dan04

खाली सेल और अशक्त दोनों कुछ चिह्नित करने का तरीका गलत है । सच नहीं। एक अशक्त मूल्य की अनुपस्थिति को इंगित करने का एक तरीका है। मैं शर्त लगाता हूं कि अधिकांश आरडीबीएमएस प्रत्येक पंक्ति पर एक बिट सरणी का उपयोग करके यह इंगित करते हैं कि कौन से कॉलम अशक्त हैं। इस प्रकार, अप्रासंगिक होने के लिए अतिरिक्त स्थान इतना छोटा है। अतिरिक्त प्रसंस्करण के बारे में चिंता करना समयपूर्व अनुकूलन है और अन्य डेवलपर्स के लिए "खोज" करने के लिए बनाए गए गति धक्कों की तुलना में कुछ भी नहीं होगा जिसे आपने जानबूझकर खाली तारों का उपयोग किया है।
थॉमस

3
कोई अशक्त मूल्य नहीं । यह शुतुरमुर्ग दृष्टिकोण है। "हम रेत में अपना सिर चिपका देंगे और घोषणा करेंगे कि अनुपस्थित मूल्य मौजूद नहीं हैं"। यह आमतौर पर मैजिक वैल्यू सॉल्यूशन की ओर ले जाता है, जहाँ आपको किसी वैल्यू की अनुपस्थिति को दर्शाने के लिए प्रत्येक डेटा टाइप के लिए मैजिक वैल्यू के साथ आना होता है।
थॉमस

1

मैं इसे डीबी के नजरिए से नहीं, बल्कि कार्यक्रम के नजरिए से देखता हूं। मुझे पता है कि यह प्रश्न SQL क्लिक के लिए है, लेकिन वास्तव में, कितने उपयोगकर्ता सीधे किसी भी डेटा तक पहुँच प्राप्त करते हैं?

एक कार्यक्रम में मुझे अशक्त / कुछ भी पसंद नहीं है। कुछ अपवाद हैं, लेकिन वे सिर्फ यही हैं। और वे अपवाद वास्तव में सिर्फ बुरे कार्यान्वयन हैं।

इसलिए यदि उपयोगकर्ता ने ईमेल में नहीं डाला है तो ऐसा कुछ होना चाहिए जो निर्धारित करता है कि यह वैध है या नहीं। यदि कोई खाली ईमेल ठीक है तो यह एक रिक्त स्ट्रिंग प्रदर्शित करता है। यदि उपयोगकर्ता ने ईमेल में नहीं डाला है और जो किसी नियम का उल्लंघन करता है तो वस्तु को यह संकेत देना चाहिए।

अशक्त होने का अर्थ पुराने स्कूल है और कुछ आधुनिक प्रोग्रामर हैं जिनके चारों ओर काम करना है।

डीबी डिज़ाइन में भी ईमेल फ़ील्ड शून्य को अनुमति नहीं दे सकती है और शून्य लंबाई स्ट्रिंग है और किसी अन्य फ़ील्ड का संकेत है कि उपयोगकर्ता इनपुट कुछ है? एक DBMS के बारे में पूछने के लिए एक बिट है? DB को मेरी राय में, न तो व्यापारिक तर्क और न ही प्रदर्शन तर्क को संभालना चाहिए। यह उस के लिए नहीं बनाया गया था और इस तरह इसे संभालने का बहुत खराब काम होता है।


ईमेल फ़ील्ड शून्य को अनुमति नहीं दे सकती है और एक शून्य लंबाई स्ट्रिंग है - सीधे शब्दों में कहें: क्योंकि कोई भी डेवलपर जो डेटाबेस के बारे में कुछ भी जानता है वह कभी भी यह उम्मीद नहीं करेगा कि खाली स्ट्रिंग जादू का अर्थ है। आप प्रत्येक डेटाबेस में मौलिक रूप से जो पहले से मौजूद हैं उसका प्रतिनिधित्व करने के लिए अपना खुद का जादू मूल्य बनाने का प्रयास कर रहे हैं: एक मूल्य की अनुपस्थिति का प्रतिनिधित्व करने के लिए एक अवधारणा। पहिया को क्यों मजबूत करें? इसके अलावा, NULLS का विचार पुराने स्कूल से बहुत दूर, बहुत दूर है। Nulls संबंधपरक डेटाबेस डिज़ाइन को समझने के लिए कीस्टोन हैं।
थॉमस

जबरदस्त हंसी। जैसा कि मैंने एक प्रोग्रामर के नजरिए से कहा है कि नल हमेशा लगभग बट में दर्द होता है और लगभग बिजनेस लॉजिक के लिए कभी जरूरी नहीं होता है। मैं व्यक्तिगत रूप से, एक डेवलपर के रूप में, संबंधपरक डिजाइन के लिए बहुत परवाह नहीं करता हूं। अगर मैंने किया तो मैं एक डीबी दोस्त बनूंगा। अगर मुझे एक DB से अशक्त मिलता है, तो मैं लगभग हमेशा इसे कुछ तर्कसंगत के रूप में परिवर्तित करता हूं, जैसे कि एक खाली स्ट्रिंग तो मेरे शानदार OOP डिज़ाइन को जादू करते हैं। रूपरेखा उन मूर्खतापूर्ण नलियों की देखभाल करती है जो दुनिया पर DBAs को बल देते हैं। मुझे पता है कि डीबी के दोस्तों को इससे निपटना होगा और मैं आपके लिए महसूस करूंगा। लेकिन एक प्रोग्रामर के रूप में मुझे नहीं करना है। मेरे पास बेहतर उपाय हैं।
ElGringoGrande

आपको "कभी नहीं" नल से निपटना होगा। तो, आप जो वर्णन करते हैं, वह शुतुरमुर्ग समाधान है जो जादू मूल्य समाधान के साथ संयुक्त है। "मैं इस तथ्य को अनदेखा करूंगा कि अनुपस्थित मूल्य मौजूद हैं और मैं सभी शून्य पूर्णांक -1 में परिवर्तित कर दूंगा"। जब तक दिन आता है जब -1 वास्तविक मूल्य है। यह ध्यान दिया जाना चाहिए कि एमएस में जेनेरिक ने जो कारण जोड़े हैं उनमें से एक डेटाबेस और एप्लिकेशन कोड के बीच बड़े पैमाने पर प्रतिबाधा बेमेल को संबोधित करना था और यह मुख्य रूप से मध्य-स्तरीय कोड में नल को व्यक्त करने के आसपास घूमता था। व्यावसायिक तर्क में भी "मूर्खतापूर्ण नल" मौजूद हैं।
थॉमस

तथ्य यह है कि कुछ पूर्णांक डीबी (या अशक्त) में अनुपस्थित है इसका मतलब यह नहीं है कि मुझे इसे -1 के साथ प्रस्तुत करना है या एक अशक्त (इंट) को बाहर निकालना है। अगर आपको लगता है कि नल से निपटने का एकमात्र तरीका है तो आप प्रोग्रामिंग को बहुत अच्छी तरह से नहीं समझते हैं। याद रखें अशक्त कुछ भी नहीं है। जैसा आपने कहा, अशक्त किसी प्रकार की डेटा संरचना में अनुपस्थित मूल्यों के लिए एक स्थान धारक का प्रतिनिधित्व करता है। इसका मतलब कुछ है। व्यापार तर्क शायद ही कभी (जो कभी नहीं के रूप में समान नहीं है) को इस अवधारणा की आवश्यकता है क्योंकि यह बीहवियर के बारे में है, डेटा नहीं। और जब यह शून्य होता है तो यह प्रतिनिधित्व करने के लिए शायद ही सबसे अच्छा तरीका है।
एलग्रिन्गोग्रांडे

यहां तक ​​कि व्यावसायिक तर्क को अनुपस्थित मूल्यों के लिए (अर्थ प्रतिनिधित्व) का हिसाब देना पड़ता है और यह मेरे अनुभव में सच है, पिछले 20 वर्षों में मैंने देखा या बनाया गया लगभग हर सिस्टम में। डेटाबेस व्यावसायिक तथ्यों को पकड़ने और संग्रहीत करने के लिए मॉडलिंग कर रहा है। यदि व्यापार तर्क डेटाबेस के साथ बातचीत करने में सक्षम होना चाहता है तो उसे पता होना चाहिए कि नल से कैसे निपटना है। चाहे वह एक कस्टम संरचना, जादू मूल्य या एक सामान्य अप्रासंगिक हो। व्यावसायिक तर्क के लिए डेटाबेस से अनुपस्थित मान की प्राप्ति और डेटाबेस से अनुपस्थित मूल्य को चिह्नित करने की क्षमता को संभालने की क्षमता की आवश्यकता होती है।
थॉमस

-1

मुझे नहीं लगता कि यह बहुत ज्यादा मायने रखता है, लेकिन जब NULL होता है तो मुझे अच्छा लगता है।

जब मैं एक तालिका में प्रदर्शित डेटा (SQL सर्वर प्रबंधन स्टूडियो में) को देखता हूं, तो मैं एक लापता मान को बेहतर ढंग से पहचान सकता हूं यदि यह कहता है कि NULL और पृष्ठभूमि अलग-अलग रंग की है।

यदि मैं एक रिक्त स्थान देखता हूं, तो मैं हमेशा सोचता हूं कि क्या यह वास्तव में खाली है या कुछ व्हाट्सएप या कुछ अदृश्य अक्षर हैं। NULL के साथ यह पहली नजर में खाली होने की गारंटी है।

यहाँ छवि विवरण दर्ज करें

मैं आमतौर पर आवेदन में मूल्यों को अलग नहीं करता, क्योंकि यह अप्रत्याशित और अजीब है कि NULL और खाली स्ट्रिंग का अर्थ कुछ अलग होगा। और ज्यादातर समय, मैं एक रक्षात्मक दृष्टिकोण अपनाता हूं और बस दोनों राज्यों से निपटता हूं। लेकिन एक मानव के रूप में, डेटा को देखते समय NULL प्रक्रिया करना आसान है।


इससे पहले किए गए 12 अंकों से अधिक कुछ भी नहीं दिया गया है और पहले ही 12 उत्तरों में समझाया गया है
gnat

@gnat: मैं असहमत हूं, जवाबों में किसी ने भी डेटा को देखने वाले मानव के पहलू का उल्लेख नहीं किया। वहाँ सिर्फ एक एकल पूर्ण मान है, लेकिन बहुत सारे मान हो सकते हैं जो एक खाली स्ट्रिंग की तरह दिखते हैं (न केवल व्हाट्सएप बल्कि अजीब-व्यवहार वाले यूनिकोड वर्ण भी हैं)। मैं इस मुद्दे के इस पहलू का उल्लेख करते हुए कोई अन्य उत्तर नहीं देख सकता।
टॉम पॉज़्रुक

जहाँ तक मैं बता सकता हूँ यह बहुत अच्छी तरह से दूसरे शीर्ष उत्तर में रखा गया था, जो 5 साल पहले पोस्ट किया गया था: "यह किसी भी प्रोग्रामर को डेटाबेस में देख रहा है ..." आदि
gnat

@gnat: मैं आपकी बात देखता हूं, हालांकि मुझे लगता है कि लेखक का मतलब एक ही बात नहीं है। मेरा मानना ​​है कि वह इस बारे में अधिक है कि NULL वैकल्पिक फ़ील्ड का अर्थ है, लेकिन रिक्त स्ट्रिंग का उपयोग आवश्यक फ़ील्ड के लिए भी किया जा सकता है, इस प्रकार NULL अनुपलब्ध मान के लिए अधिक तार्किक है। मैं उसके साथ सहमत हूँ। लेकिन मेरा जवाब इस बात की ओर इशारा करता है कि खाली स्ट्रिंग NULL मान की तरह असंदिग्ध नहीं है, क्योंकि कई चीजें पहली नजर में खाली तार की तरह दिख सकती हैं जबकि वास्तव में खाली स्ट्रिंग नहीं होती हैं।
टॉम पॉज़्रुक
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.