2009-07-09 19 views
27

क्या MySQL में टेक्स्ट फ़ील्ड के लिए default null या default "" का उपयोग करना बेहतर है?MySQL: NULL बनाम ""

क्यों?

अद्यतन: मुझे पता है कि उनमें से प्रत्येक का क्या अर्थ है। मुझे दिलचस्पी है कि डिस्क स्पेस और प्रदर्शन पर विचार करने के लिए बेहतर क्या है।

अद्यतन 2: हे पीपीएल! सवाल "क्या उपयोग करना बेहतर है" नहीं "प्रत्येक का क्या मतलब है" या "उन्हें कैसे जांचें" ...

+2

अधिकांश "डिस्क स्थान और प्रदर्शन के लिए बेहतर क्या है" प्रश्नों के साथ: आप न्यूल के साथ एक लाख पंक्तियां क्यों नहीं डालते हैं, कुछ प्रश्नों का परीक्षण करते हैं, और डिस्क स्थान की जांच करते हैं? एस के साथ दोहराएं, और एक बार अपेक्षाकृत मिश्रण के साथ। और उत्तर एसओ पर कुछ यादृच्छिक लड़के की तुलना में अधिक विश्वसनीय है;) – ojrac

+1

हाहा, मुझे अपडेट टिप्पणियां पसंद हैं – Xeoncross

उत्तर

29

डिफ़ॉल्ट null का उपयोग करें। एसक्यूएल में, null खाली स्ट्रिंग ("") से बहुत अलग है। खाली स्ट्रिंग का विशेष अर्थ है कि मान खाली होने के लिए सेट किया गया था; null का अर्थ है कि मान सेट नहीं किया गया था, या शून्य पर सेट किया गया था। अलग-अलग अर्थ, आप देखते हैं।

विभिन्न अर्थ और उनके विभिन्न उपयोग इसलिए हैं कि उनमें से प्रत्येक को उपयुक्त के रूप में उपयोग करना महत्वपूर्ण है; का उपयोग करके default "" के विपरीत संभावित रूप से सहेजी गई जगह की मात्रा इतनी छोटी है कि यह लापरवाही तक पहुंचती है; हालांकि, सम्मेलन निर्देशों के रूप में उचित चूक का उपयोग करने का संभावित मूल्य काफी अधिक है।

+1

हां, इस तरह आप किसी भी वैध "खाली मूल्य" – AndyMcKenna

+0

से अलग नहीं कर सकते हैं http://stackoverflow.com/questions/1034925/is-an-overuse-of-nullable-columns-in-a-database-a-code-smell, जिस पर इस मामले पर कुछ शानदार चर्चाएं हैं। – hythlodayr

+4

ओरेकल में 'IS NULL – borjab

3

जो कुछ भी समझ में आता है उसका उपयोग करें। NULL का अर्थ है "कोई मूल्य उपलब्ध/निर्दिष्ट नहीं है", "" का अर्थ है "खाली स्ट्रिंग।"

यदि आप खाली तारों की अनुमति नहीं देते हैं, लेकिन उपयोगकर्ता को कोई मान दर्ज नहीं करना है, तो NULL समझ में आता है। यदि आपको एक मूल्य की आवश्यकता है, लेकिन यह खाली हो सकता है, NOT NULL और "" का मान समझ में आता है।

और, यदि आपको कोई मूल्य की आवश्यकता नहीं है, लेकिन एक खाली मान निर्दिष्ट किया जा सकता है, तो NULL समझ में आता है।

एक दक्षता बिंदु को देखते हुए, यह निर्धारित करने के लिए कि अतिरिक्त क्षेत्र NULL है या नहीं, लेकिन इस तरह के सूक्ष्म अनुकूलन के बारे में परेशान न करें जब तक आपके पास लाखों पंक्तियां न हों।

+0

मेरी इच्छा है कि ओरेकल को यह एहसास हो जाएगा :) –

+0

+1 मैं सहमत हूं, व्यवसाय डोमेन –

+0

I के अनुसार एक अर्थपूर्ण अर्थ है। डिस्क स्थान या प्रदर्शन पर कोई महत्वपूर्ण अंतर की उम्मीद नहीं करेगा। – davidcl

0

"" एक खाली बॉक्स की तरह है ... null कोई बॉक्स नहीं है।

शुरुआत में समझना एक कठिन अवधारणा है, लेकिन यहां के जवाब स्पष्ट रूप से राज्य हैं - इसमें एक बड़ा अंतर है।

0

सामान्य रूप से, NULL को उस डेटा को इंगित करना चाहिए जो मौजूद नहीं है या आपूर्ति नहीं की गई है, और इसलिए खाली स्ट्रिंग से बेहतर डिफ़ॉल्ट मान है।

कभी-कभी खाली स्ट्रिंग वह होती है जो आपको डेटा मान के रूप में चाहिए, लेकिन यह लगभग डिफ़ॉल्ट मान कभी नहीं होना चाहिए।

0

न्यूल का अर्थ है 'कोई मूल्य नहीं है' और विशेष रूप से आरडीबीएमएस द्वारा क्लॉज और जुड़ने के संबंध में इसका इलाज किया जाता है।

"" का अर्थ है 'खाली स्ट्रिंग' और विशेष रूप से इलाज नहीं किया जाता है।

यह इस बात पर निर्भर करता है कि टेक्स्ट क्या दर्शाता है और वास्तव में प्रश्नों में इसका उपयोग कैसे किया जाएगा।

उदाहरण के लिए, आप कुछ अनिवार्य प्रश्नों और कुछ वैकल्पिक प्रश्नों के साथ प्रश्नावली कर सकते हैं।

  • अस्वीकृत वैकल्पिक प्रश्नों को उनके संबंधित कॉलम में एक पूर्ण होना चाहिए।
  • अनिवार्य प्रश्नों में डिफ़ॉल्ट रूप से खाली स्ट्रिंग होना चाहिए, क्योंकि उनका उत्तर दिया जाना चाहिए। (एक वास्तविक आवेदन में बेशक आप कुछ दर्ज करने के लिए उपयोगकर्ता बता चाहते हैं, लेकिन मुझे आशा है कि आप विचार प्राप्त)
0

'' = '' पैदावार TRUE जो WHERE हालत

NULL = NULL पैदावार NULL जो संतुष्ट नहीं करता संतुष्ट WHERE स्थिति

जो उपयोग करने के लिए बेहतर है, इस पर निर्भर करता है कि आप क्या परिणाम प्राप्त करना चाहते हैं।

यदि आपका मान डिफ़ॉल्ट NULL करने के लिए, इस तरह कोई क्वेरी:

SELECT * 
FROM mytable 
WHERE col1 = ? 

कभी इन मूल्यों को वापस आ जाएगी, भले ही आप बाध्य पैरामीटर के लिए NULL गुजरती हैं, इस क्वेरी जबकि:

SELECT * 
FROM mytable 
WHERE col1 = '' 

आपको उन पंक्तियों को वापस कर देगा जिन्हें आपने खाली स्ट्रिंग पर सेट किया था।

यह MySQL के लिए सच है, लेकिन Oracle के लिए नहीं है, जो खाली स्ट्रिंग और NULL के बीच अंतर नहीं करता है।

Oracle में, बाद की क्वेरी कभी भी वापस नहीं आएगी।

7

लोगों का एक बहुत का जवाब दे रहे हैं उस पर क्या null और '' के बीच का अंतर है, लेकिन ओ पी का अनुरोध किया है क्या कम जगह लेता है/है तेज, इसलिए यहाँ मेरी वार है:

जवाब यह है कि है निर्भर करता है। यदि आपका क्षेत्र char(10) है, तो यह हमेशा 10 बाइट्स लेगा यदि null पर सेट नहीं है, और इसलिए null कम जगह लेगा। पंक्ति-दर-पंक्ति आधार पर मिनट, लेकिन लाखों और लाखों पंक्तियों से अधिक, यह जोड़ सकता है। मेरा मानना ​​है कि varchar(10) एक बाइट (\0) को खाली स्ट्रिंग के रूप में स्टोर करेगा, फिर भी यह विशाल टेबल पर जोड़ सकता है।

प्रश्नों में प्रदर्शन के संदर्भ में, null सिद्धांत में तेजी से परीक्षण करने के लिए है, लेकिन मैंने अच्छी तरह से अनुक्रमित तालिका पर किसी भी सराहनीय अंतर के साथ आने में सक्षम नहीं देखा है। हालांकि ध्यान रखें कि अगर आपको वांछित वापसी है तो आपको आवेदन पक्ष पर null'' में परिवर्तित करना पड़ सकता है। फिर, पंक्ति-दर-पंक्ति, अंतर मिनट है, लेकिन यह संभावित रूप से जोड़ सकता है।

सब कुछ माइक्रो-ऑप्टिमाइज़ेशन है, इसलिए यह वरीयता के लिए उबाल जाता है। मेरी प्राथमिकता null का उपयोग करना है क्योंकि मुझे यह जानना है कि वहां कोई मूल्य नहीं है, और अनुमान नहीं है कि यह एक खाली स्ट्रिंग ('') या रिक्त स्थान (' ') है। null इसकी प्रकृति में स्पष्ट है। '' नहीं है। इसलिए, मैं null के साथ जाता हूं क्योंकि मैं एक स्पष्ट प्रकार का लड़का हूं।

0

"" का प्रयोग करें। यदि आप यह कह सकते हैं कि कॉलम गैर-शून्य हैं तो इसे कम प्रोग्रामिंग प्रयास की आवश्यकता होती है। इनके बीच अंतरिक्ष अंतर मामूली है।

44

MyISAM तालिकाओं के लिए, NULL प्रत्येक पंक्ति के लिए प्रत्येक संक्षिप्त स्तंभ (शून्य बिट) के लिए एक अतिरिक्त बिट बनाता है। यदि कॉलम पूर्ण नहीं है, तो जानकारी के अतिरिक्त बिट की आवश्यकता नहीं होती है। हालांकि, यह 8 बिट बाइट्स तक गद्देदार है ताकि आप हमेशा कॉलम की गिनती के लिए 1 + mod 8 बाइट प्राप्त कर सकें। 1

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

इनो डीबी में, न्यूल में कोई जगह नहीं है: वे बस डेटा सेट में मौजूद नहीं हैं। खाली स्ट्रिंग के लिए भी यही सच है क्योंकि डेटा ऑफ़सेट मौजूद नहीं है। केवल अंतर यह है कि एनयूएलएल के पास नल बिट सेट होगा जबकि खाली तार नहीं होंगे। 2

जब डेटा वास्तव में डिस्क पर रखा जाता है, न्यूल और 'दोनों डेटा प्रकारों में बिल्कुल समान स्थान लेते हैं। हालांकि, जब मूल्य की खोज की जाती है, तो एनयूएलएल की जांच थोड़ा तेज़ होती है और फिर '' की जांच होती है क्योंकि आपको अपनी गणना में डेटा लंबाई पर विचार नहीं करना पड़ता है: आप केवल शून्य बिट की जांच करते हैं।

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

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

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

उलटा-सामान्य शर्तों (और दार्शनिक दृष्टिकोण से) डिफ़ॉल्ट कॉलम के लिए डिफ़ॉल्ट नल को प्राथमिकता दी जाती है क्योंकि यह "कोई मूल्य निर्दिष्ट नहीं" की सर्वोत्तम अर्थपूर्ण व्याख्या देता है।

1 [http://forge.mysql.com/wiki/MySQL_Internals_MyISAM]

2 [http://forge.mysql.com/wiki/MySQL_Internals_InnoDB]

+0

अरे, यह एक महान स्पष्टीकरण है। धन्यवाद –

1

मैं अशक्त पसंद करते हैं जब यह अर्थ की दृष्टि से सही है। यदि कोई पता फ़ील्ड उपलब्ध है और उपयोगकर्ता भर नहीं गया है, तो मैं इसे "" देता हूं। हालांकि यदि उपयोगकर्ता तालिका में किसी पते की विशेषता में अभी तक मैंने उपयोगकर्ता को इसे भरने का मौका नहीं दिया है, तो मैं इसे एक पूर्ण देता हूं।

मुझे संदेह है (लेकिन मैं सत्यापित नहीं कर सकता) कि न्यूल और "" बहुत अंतर बनाता है।

5

मुझे पता चला कि डिस्क बनाम और प्रदर्शन के मामले में न्यूल बनाम "" महत्वहीन है।

एकमात्र सच्चा कारण मैं व्यक्तिगत रूप से न्यूल ओवर 'का उपयोग करने में देख सकता हूं, जब आपके पास UNIQUE के रूप में चिह्नित फ़ील्ड है लेकिन कई "खाली" कॉलम को अनुमति देने की क्षमता की आवश्यकता है।

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

18

से High Performance MySQL, 3rd Edition

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

+1

स्ट्रिंग कॉलम में सभी नल को खाली स्ट्रिंग में परिवर्तित कर रहा है और कॉलम को नल * वास्तव में * किसी भी मापनीय सीमा तक प्रदर्शन में सुधार कर रहा है? विचार है कि किसी को निष्पादन कारणों से निरर्थक कॉलम से बचना चाहिए, जिसे मैंने अभी तक कभी नहीं सुना है, और मुझे तुरंत इसके बारे में संदेह है। –

+0

> नल कॉलम को नल में बदलने से प्रदर्शन सुधार आमतौर पर छोटा –

+1

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

संबंधित मुद्दे