क्यों समझते हैं कि 2, 4, 8, 16, 32, 64, 128, 256 ... बाइनरी अंकों के दशमलव समकक्ष हैं।डेटाबेस स्कीमा में अक्सर 32, 64, 128, आदि
क्या ऐसा कोई कारण है कि इनका उपयोग डेटाबेस में क्यों किया जाता है? उदाहरण के लिए, VARCHAR फ़ील्ड अक्सर 255 वर्ण लंबे होते हैं। चूंकि (मैं मान रहा हूं) प्रत्येक चरित्र एक बाइट है, 255 वर्णों का उपयोग करने और 257 वर्णों का उपयोग करने के बीच कोई अंतर क्यों है?
varchar कॉलम के साथ
, लंबाई साथ संग्रहीत किया जाता है डेटा के अग्रणी बाइट में अहस्ताक्षरित पूर्णांकों का उपयोग कर डेटा। बाइट्स की सबसे कम संख्या का उपयोग किया जाता है; एक बाइट लंबाई 0 से 255 तक, 0 से 65535 तक दो बाइट स्टोर कर सकता है। लंबाई 255 बनाकर, आपको न्यूनतम एक लंबाई बाइट से "सबसे अधिक मूल्य" मिलता है।
दिनों में चला गया, प्रति पंक्ति सहेजी गई डिस्क के एकल बाइट्स बचत के लायक थे। हालांकि अब डिस्क सस्ता है, लेकिन विशेष रूप से ग्रे-बालों वाले डीबीए द्वारा सोच बनी हुई है।
लंबाई की लंबाई चुनने में कोई फायदा नहीं है, उदाहरण के लिए varchar(64) - यह केवल एक आदत/सम्मेलन है (मैं इसका भी पालन करता हूं - और मुझे नहीं पता क्यों!)।
न केवल डेटाबेस स्कीमा बल्कि किसी भी प्रोग्रामिंग आर्टिफैक्ट में फॉर्म 2^एन या 2^एन -1 के कई नंबर शामिल होंगे। हालांकि इनमें से कुछ उपयोग समझ में आते हैं (उदाहरण के लिए 2^32-1 कई मशीन आर्किटेक्चर में एक मानक हस्ताक्षरित पूर्णांक के रूप में प्रतिनिधित्व करने वाला सबसे बड़ा नंबर है), 2 की शक्तियों के अधिकांश उपयोग कम आवश्यक हैं। प्रैक्टिस में, पुराने हैकर्स 2 की शक्तियों को पवित्र मानते हैं, और उन्हें पूजा करते हैं।
जब आप अपने डेटा के हेक्स डंप देखते हैं तो चीजें अच्छी तरह से बढ़ने जा रही हैं? ;-) – mpontillo
डेटाबेस में डेटा को अक्सर pages में व्यवस्थित किया जाता है। ये पृष्ठ लगभग सार्वभौमिक स्मृति और कैश प्रबंधन के लिए स्मृति सीमाओं के साथ गठबंधन हैं। अपने डेटा के लिए 2^एन आकार चुनना आपके डेटाबेस में स्थान के उपयोग को अनुकूलित करने के लिए अच्छा है।
नोट: आरडीबीएमएस इंजन के आधार पर, 256 मेमोरी संरेखण परिप्रेक्ष्य से परिवर्तनीय-लंबाई तारों के लिए सबसे अच्छा विकल्प नहीं हो सकता है, क्योंकि स्ट्रिंग की लंबाई भी जगह लेती है, यानी varchar(256) 258 बाइट्स लेता है।
जब तक डेटा आकार तय नहीं होते हैं (char/nchar), यह अलग-अलग लंबाई कॉलम के लिए सही नहीं है, जो इन जादू संख्याओं का उपयोग करके परिभाषित होने की अधिक संभावना है, और जो शायद ही कभी पूरी तरह से आबादी में हैं और इसलिए नहीं समान रूप से अच्छे छोटे ब्लॉक में एक पृष्ठ भरें। –
@AaronBertrand यही वह बिंदु है जिसने मैंने जवाब के अंत में नोट बनाने की कोशिश की: 'वर्कर' कॉलम के लिए 2^एन संख्या पृष्ठ संरेखण में मदद करने की संभावना नहीं है। – dasblinkenlight
क्षमा करें, मैंने पहले पैराग्राफ को खत्म करने के बाद अपनी टिप्पणी शुरू की। यदि अन्य लोग भी आपका नोट नहीं पढ़ते हैं तो बस "डेटा" के बजाय "निश्चित डेटा" के बारे में कुछ कहने का सुझाव दें। :-) –
यह किसी भी चीज़ की तुलना में अधिक आदत है। वर्कर (32) या वर्कर (64) के बारे में जादू कुछ भी नहीं है, इसी प्रकार दृश्य उपकरण के बजाय जादू का उपयोग करने की कोशिश करने के बजाए जादू के कुछ भी नहीं है (उदाहरण के लिए वर्कर (50))। इन ऊपरी सीमाओं में से कई लोगों के सिर में शामिल हो गए हैं क्योंकि 640k किसी के लिए पर्याप्त स्मृति होगी और हमें वास्तव में हर एक बाइट के बारे में चिंता करने की ज़रूरत है।
कई मामलों में यह एक आम जमीन पर आता है। पिछली प्रणाली में मैंने उत्पाद प्रबंधकों में काम किया था, उन्हें पता नहीं था कि उनकी आवश्यकताएं क्या थीं। वे एक नाम स्टोर करना चाहते थे, लेकिन उन्हें नहीं पता था कि नामों के डोमेन में वास्तव में क्या शामिल है - लेकिन उनमें से एक ने कहा कि उन्होंने अंतिम नाम> 50 वर्णों के बारे में सुना था, इसलिए उन्हें पता था कि यह 32 से अधिक होना चाहिए और 50 से अधिक। हम 64 के साथ वापस आए, वह इस बात पर सहमत हुए कि वह पर्याप्त था, और यही वह है जो आज भी AFAIK है।
हालांकि हमारे पास ई-मेल (वर्चर (320)) का तकनीकी कारण था, उस समय मानक मानक 320 अक्षरों के रूप में निर्धारित किया गया था क्योंकि उपयोगकर्ता नाम/स्थानीय भाग के लिए 64 वर्ण, डोमेन नाम के लिए 255 वर्ण, और 1 वर्ण @। अधिकांश अन्य निर्णय प्राथमिकता पर आधारित थे (उदाहरण के लिए सभी बाद के नाम ऊपर दिए गए अनुसार nvarchar (64) मॉडल का पालन करते हैं), या तर्क (जैसे यूआरएल को nvarchar (अधिकतम) होने की आवश्यकता नहीं है, लेकिन मानक और ब्राउज़र क्षमताओं के आधार पर समय, वे या तो वर्चर (2048) या वर्कर (40 9 6) पर विश्वास करते थे। उस मामले में ऐसा नहीं था क्योंकि यह 2 की शक्ति थी, लेकिन क्योंकि किसी और के सॉफ्टवेयर या मानकों ने 2 की शक्ति का उपयोग करने के लिए अपनी सामग्री बनाई थी।
+1 क्योंकि आप (मुझे लगता है) परामर्श मानकों की सिफारिश करते हैं उदा। व्यक्ति के परिवार के नाम के लिए मैं [देश के सरकारी डेटा मानकों] से मेल खाने के लिए 'वर्चर (35)' का उपयोग करूंगा (http://interim.cabinetoffice.gov.uk/govtalk/schemasstandards/e-gif/datastandards/person_information/person_name/ person_full_name.aspx), आंशिक रूप से क्योंकि मेरा सॉफ़्टवेयर सरकारी डेटाबेस से बातचीत करने की संभावना है, लेकिन यह भी कि किसी ने यह निर्धारित करने के लिए विश्लेषण किया है कि 35 गैर-यूनिकोड वर्ण एक उचित बाधा है ताकि मुझे यह नहीं करना पड़े! – onedaywhen
हां, बिल्कुल, अगर आपके उद्योग के लिए डेटा मानकों हैं, तो आपको उनका उपयोग करना चाहिए। लेकिन आपके ग्राहक और उत्पाद प्रबंधक - जो आपके ग्राहक भी हैं - अक्सर अन्यथा निर्देशित कर सकते हैं, और उनका ट्रम्प आम तौर पर मानक के ट्रम्प को धड़कता है (जब तक वे बेवकूफ या हास्यास्पद नहीं होते)। और वे जांच करेंगे कि क्या आप वास्तव में 64-वर्ण के आखिरी नाम की अनुमति देते हैं, मेरा विश्वास करो। :-) –
मुझे आश्चर्य है कि, अगर कोई 'वर्चर' के बजाय 'NVARCHAR' का उपयोग करने का सुझाव देता है, तो मुझे [जो सेल्को की किताब से बाहर एक पत्ता] लेने में उचित ठहराया जाएगा (http://books.google.co.uk/books ? id = a9jtyioHfp8C और स्नातकोत्तर = PA131 और रसोई गैस = PA131 और डीक्यू = celko + बौद्ध और स्रोत = बीएल और ओ टी एस = Py_oNKC6_h और sig = d9MRYEcVlI-Noi03XWLaDhAv6WM & hl = hi & सा = एक्स और Ei = D0VGT6SzAYbN0QXa7KmmDg और वेद = 0CCAQ6AEwAA # v = onepage & q & f = गलत) और वहाँ में चीनी यूनिकोड डाल? ;) – onedaywhen
ओच। मेरे पास भूरे बाल हैं लेकिन मैं पुराना नहीं हूं (38)। :-) –
हम्म, हालांकि बड़ी टेबलों में जहां आपको चयन कॉल करने की आवश्यकता है, जिसमें बहुत से I/Os की आवश्यकता होती है, पंक्ति आकार के कुछ बाइट्स को सहेजना * * एक अंतर बना सकता है। (लेकिन आप VARCHAR लंबाई के बारे में बिल्कुल सही हैं :) – osman
@osman हाँ - अधिक पंक्तियों और/या इंडेक्स प्रविष्टियां जो आप डिस्क के 1 पृष्ठ में फिट प्रदर्शन कर सकते हैं बेहतर प्रदर्शन। – Bohemian