हम आम तौर पर हमारे सभी varchar/nvarchar कॉलम गैर-शून्य को एक खाली स्ट्रिंग ('') के साथ डिफ़ॉल्ट मान के रूप में पसंद करते हैं। टीम का कोई सदस्य ने सुझाव दिया कि नल बेहतर है क्योंकि:निरर्थक बनाम गैर-शून्य वर्कर डेटा प्रकार - जो प्रश्नों के लिए तेज़ है?
इस तरह एक क्वेरी:
Select * From MyTable Where MyColumn == ''
किसी को मान्य करने के लिए यह है कि क्या कोई अनुभव:
Select * From MyTable Where MyColumn IS NOT NULL
इस की तुलना में तेजी है सच?
कुछ प्लेटफ़ॉर्म (और यहां तक कि संस्करण) पर, यह इस बात पर निर्भर करेगा कि एनयूएलएल कैसे अनुक्रमित होते हैं।
मेरे NULLs के लिए अंगूठे का बुनियादी नियम है:
NULLs जब तक अनुमति न दें उचित
जब तक डेटा NULLs वास्तव में अज्ञात हो सकता है की अनुमति न दें
इसका एक अच्छा उदाहरण मॉडलिंग पता लाइनों है। यदि आपके पास एड्रेसलाइन 1 और एड्रेसलाइन 2 है, तो पहले डेटा के लिए इसका मतलब क्या है और दूसरा नल होना चाहिए? ऐसा लगता है, आप या तो पता जानते हैं या नहीं, और डेटा के एक सेट में आंशिक एनयूएलएल होने पर केवल परेशानी के लिए पूछता है जब कोई उन्हें जोड़ता है और न्यूल (एएनएसआई व्यवहार) प्राप्त करता है। आप इसे एनयूएलएल की अनुमति देने और चेक बाधा जोड़ने के साथ हल कर सकते हैं - या तो सभी पता जानकारी पूर्ण है या कोई भी नहीं है।
मध्यम प्रारंभिक/नाम के साथ समान बात। कुछ लोगों में एक नहीं है। क्या यह अज्ञात होने से अलग है और क्या आपको परवाह है?
भी, मृत्यु की तारीख - शून्य का क्या अर्थ है? मरा नहीं? मौत की अज्ञात तारीख? डोमेन में ज्ञान को एन्कोड करने के लिए कई बार एक कॉलम पर्याप्त नहीं होता है।
मेरे लिएतो, NULLs अर्थ विज्ञान डेटा पहले की पर बहुत ज्यादा निर्भर करेगा अनुमति देनी है या - क्योंकि डेटा की गलत व्याख्या होने (संभावित कई अलग अलग लोगों द्वारा), प्रदर्शन दूसरे होने जा रहा है आम तौर पर एक कहीं अधिक महंगा है प्रदर्शन से समस्या।
यह एक छोटी सी चीज की तरह प्रतीत हो सकता है (SQL सर्वर में कार्यान्वयन पंक्ति के साथ संग्रहीत बिटमैस्क है), लेकिन औचित्य के बाद केवल एनयूएलएल को अनुमति देने के लिए मुझे सबसे अच्छा काम करने लगता है। यह चीजों को विकास में जल्दी पकड़ता है, आपको धारणाओं को संबोधित करने और अपनी समस्या डोमेन को समझने के लिए मजबूर करता है।
मृत्यु की तिथि के रूप में: एनयूएलएल का मतलब यह होगा कि कोई ज्ञात तारीख नहीं है।इस मामले में, शून्य का उपयोग उचित है, क्योंकि आप खोजना चाहते हैं, उदाहरण के लिए, सबसे पुरानी तारीख दर्ज की गई है, या मृत लोगों की गणना (NULL गिना नहीं जाता है)। एक ही बात मध्य नाम पर लागू होती है, अगर आप कभी जानना चाहेंगे कि आपके डेटाबेस में कितने लोग हैं। – Mewp
@Mewp आप COUNT (DtOfDeath) द्वारा लोगों की गिनती नहीं कर सकते हैं, हमेशा मृत लोग रहते हैं जहां आप जानते हैं कि वे मर चुके हैं लेकिन आप मृत्यु की तारीख नहीं जानते हैं (या यह एक संभावित सीमा है - जैसा कि हम अपने अनुभव से जानते हैं कैटरीना के बाद न्यू ऑरलियन्स)। मेरा मुद्दा यह है कि आपको यह सोचना होगा कि समस्या का डोमेन सफलतापूर्वक मॉडल करने के लिए आप डेटा का उपयोग कैसे करना चाहते हैं और आप क्या जानते हैं। –
यदि आप जानना चाहते हैं कि कोई मूल्य नहीं है, तो NULL का उपयोग करें।
गति के लिए, आईएसएलएल तेज होना चाहिए, क्योंकि यह स्ट्रिंग तुलना का उपयोग नहीं करता है।
उस लड़के को अपनी टीम पर अपने पहले से ऑप्टिमाइज़िन 'अपने गधे से बाहर निकालने के लिए बताएं! (लेकिन एक अच्छा तरीका में)।
ऐसे डेवलपर्स टीम के लिए जहरीले हो सकते हैं, जो निम्न स्तर के अनुकूलन मिथकों से भरे हुए हैं, जिनमें से सभी कुछ विशिष्ट विक्रेता या क्वेरी पैटर्न के लिए एक बिंदु पर सच हो सकते हैं या संभवतः सत्य हैं सिद्धांत लेकिन अभ्यास में कभी सच नहीं है।इन मिथकों पर कार्य करना समय की महंगी बर्बादी है, और अन्यथा अच्छी डिजाइन को नष्ट कर सकता है।
वह शायद अच्छी तरह से मतलब है और टीम के लिए अपने ज्ञान का योगदान करना चाहता है। दुर्भाग्य से, वह गलत है। इस बात के अर्थ में गलत नहीं है कि बेंचमार्क अपना बयान सही या गलत साबित करेगा या नहीं। वह इस अर्थ में गलत है कि यह नहीं है कि आप डेटाबेस कैसे डिज़ाइन करते हैं। फ़ील्ड के प्रकार को परिभाषित करने के प्रयोजनों के लिए डेटा के डोमेन के बारे में कोई प्रश्न नहीं है, इस सवाल का सवाल है। इस क्षेत्र के लिए इसका कोई मतलब नहीं है कि इसका कोई मतलब नहीं है।
संक्षेप में, नल = अज्ञात! .. जिसका अर्थ है (मृत्यु उदाहरण की तारीख का उपयोग करके) कि इकाई 1) जीवित हो सकती है, 2) मृत लेकिन मृत्यु की तारीख ज्ञात नहीं है, या 3) अज्ञात अगर इकाई है जिंदा या मुर्दा। संख्यात्मक कॉलम के लिए मैं हमेशा उन्हें 0 (ZERO) में डिफ़ॉल्ट करता हूं क्योंकि लाइन के साथ कहीं भी आपको कुल गणना और शून्य + 123 = NULL करना पड़ सकता है। अल्फान्यूमेरिक्स के लिए मैं कम से कम महंगी प्रदर्शन-वार और 'कहां से एक IS NULL' कहने के लिए आसान कहता हूं ... जहां एक = "" '। 'का उपयोग करना ... जहां एक = "" [स्पेस]' एक अच्छा विचार नहीं है क्योंकि [अंतरिक्ष] एक पूर्ण नहीं है! तिथियों के लिए, यदि आपको दिनांक कॉलम न्यूल छोड़ना है, तो आप एक स्टेटस इंडिकेटर कॉलम जोड़ना चाहेंगे, जो उपर्युक्त उदाहरण में ए = एलीव, डी = डेड, क्यू = डेड, मौत की तारीख ज्ञात नहीं है, एन = जीवित या मृत अज्ञात है।
यदि आपको न्यूल की आवश्यकता है, तो न्यूल का उपयोग करें। खाली स्ट्रिंग ditto।
प्रदर्शन के लिए के रूप में, "यह निर्भर करता है"
आप varchar है, तो आप लंबाई के लिए पंक्ति में एक वास्तविक मूल्य भंडारण कर रहे हैं। यदि आपके पास char है, तो आप वास्तविक लंबाई को स्टोर करते हैं। इंजन के आधार पर न्यूल को पंक्ति में संग्रहीत नहीं किया जाएगा (उदाहरण के लिए SQL सर्वर के लिए पूर्ण बिटमैप)।
इसका मतलब यह है शून्य है तेज, क्वेरी के लिए क्वेरी है, लेकिन यह COALESCE/NULLIF/IsNull जटिलता जोड़ सकते हैं।
तो, अपने सहकर्मी आंशिक रूप से सही है, लेकिन यह पूरी तरह से सराहना नहीं कर सकते।
आँख बंद करके खाली स्ट्रिंग का उपयोग कर एक प्रहरी मूल्य नहीं बल्कि उसके बाद शून्य अर्थ मुद्दा
FWIW और व्यक्तिगत रूप से के माध्यम से काम का उपयोग है:
मैं करते हैं शून्य उपयोग करने के लिए है, लेकिन हमेशा नहीं है । मुझे 31 दिसंबर 99 99 जैसी तिथियों से बचना पसंद है, जहां नल से बचने से आपको नेतृत्व होता है।
कैड रॉक्स के जवाब से ... मैं भी लगता है कि के बारे में चर्चा व्यर्थ "मौत व्यर्थ की तारीख है"। एक क्षेत्र के लिए, व्यावहारिक शर्तों में, या तो कोई मूल्य है या नहीं है।
प्रहरी मूल्यों बदतर तो NULLs हैं। जादू संख्याएं किसी को?
31 दिसंबर 99 99, डेटाबेस में मैंने विरासत में यह 1/1/1900 है, इसलिए कष्टप्रद। – AMissico
ओरेकल के तहत कम से कम, एक खाली स्ट्रिंग भी 'NULL' माना जाता है। – zneak
मेरा अनुभव: MySQL के तहत नहीं। – MvanGeest
आपके उदाहरण समान नहीं हैं। या तो पहला 'MyColumn IS NULL' होना चाहिए, या दूसरा 'MyColumn <>' 'होना चाहिए। –