ऐतिहासिक रूप से लोग डेटाबेस फ़ील्ड परिमाण के लिए 255 नहीं 256 का उपयोग क्यों करते हैं?


189

आप अक्सर डेटाबेस फ़ील्ड को 255 वर्णों का परिमाण सेट करते देखते हैं, पारंपरिक / ऐतिहासिक कारण क्या है? मुझे लगता है कि यह पेजिंग / मेमोरी सीमा और प्रदर्शन के साथ कुछ करना है, लेकिन 255 और 256 के बीच के अंतर ने मुझे हमेशा भ्रमित किया है।

varchar(255)

यह देखते हुए कि यह क्षमता या परिमाण है, सूचकांक नहीं है , 256 को 256 से अधिक क्यों पसंद किया जाता है? क्या कोई बाइट किसी उद्देश्य (टर्मिनेटर या अशक्त या कुछ) के लिए आरक्षित है?

संभवतया वर्चर (0) एक बकवास है (शून्य क्षमता है)? किस स्थिति में 2 ^ 8 का स्थान निश्चित रूप से 256 होना चाहिए?

क्या अन्य परिमाण हैं जो प्रदर्शन लाभ प्रदान करते हैं? उदाहरण के लिए, varchar (512) varchar (511) या varchar (510) की तुलना में कम प्रदर्शन करने वाला है?

क्या यह मूल्य सभी संबंध डेटाबेस, पुराने और नए के लिए समान है?

डिस्क्लेमर - मैं एक डेवलपर हूं जो डीबीए नहीं है, मैं फील्ड साइज और प्रकारों का उपयोग करता हूं जो मेरे व्यावसायिक तर्क के अनुकूल हैं जहां यह ज्ञात है, लेकिन मैं इस वरीयता के लिए ऐतिहासिक कारण जानना चाहूंगा , भले ही यह प्रासंगिक नहीं हो (लेकिन यहां तक ​​कि अधिक अगर यह अभी भी प्रासंगिक है)।

संपादित करें:

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

यदि मेटा डेटा (स्ट्रिंग लंबाई) को एक ही सन्निहित मेमोरी / डिस्क में संग्रहीत किया जाता है, तो यह कुछ समझ में आता है। मेटाडेटा के 1 बाइट और स्ट्रिंग डेटा के 255 बाइट्स, एक-दूसरे को बहुत अच्छी तरह से सूट करेंगे, और स्टोरेज के 256 सन्निहित बाइट्स में फिट होंगे, जो संभवतः साफ-सुथरा है।

लेकिन ... यदि मेटाडेटा (स्ट्रिंग की लंबाई) वास्तविक स्ट्रिंग डेटा (शायद मास्टर तालिका में) से अलग संग्रहीत की जाती है, तो स्ट्रिंग के डेटा की लंबाई को एक बाइट द्वारा बाधित करने के लिए, सिर्फ इसलिए कि केवल 1 बाइट पूर्णांक को स्टोर करना आसान है मेटाडेटा थोड़ा अजीब लगता है।

दोनों ही मामलों में, यह एक सूक्ष्मता प्रतीत होगी जो संभवतः DB कार्यान्वयन पर निर्भर करती है। 255 का उपयोग करने का अभ्यास बहुत व्यापक लगता है, इसलिए किसी व्यक्ति ने शुरुआत में इसके लिए एक अच्छे मामले का तर्क दिया होगा, क्या कोई याद कर सकता है कि वह मामला क्या था / है? प्रोग्रामर बिना किसी कारण के कोई नया अभ्यास नहीं अपनाएंगे, और यह एक बार नया रहा होगा।


3
क्योंकि वर्ण गणना 0 से N-1 से शुरू होती है। तो 256 वर्णों को varchar (255) घोषित किया जाएगा। जब तक मैं गलत नहीं हूँ।
बुहाके सिंडी

3
शायद इसलिए कि आईटी के लोग 0, 1 से नहीं;) के साथ गिनना शुरू करते हैं?
रोमेन लिंसोलास

मुझे लगता है कि यह पुराने स्कूल प्रोग्रामर के साथ करना है, यह भी याद नहीं है कि हमने ऐसा क्यों किया।
क्रोधी

7
@ एलीट जेंटलमैन: कोष्ठक में संख्या को नापना सही लंबाई है ... जैसे सी सरणी घोषणाओं में: x [256] x [0] ... x [255] देता है।
RedPandaCurios

@romaintaz - लेकिन एक सरणी पर विचार करें जो 1 आइटम को स्टोर कर सकती है। आप इसे कुछ [1] घोषित करते हैं और इसे कुछ [0] तक पहुँचाते हैं। सवाल यह है कि एसक्यूएल में हम पहली नज़र में तार्किक प्रतीत होने की तुलना में 1 बाइट कम होने की क्षमता क्यों घोषित करते हैं।
एंड्रयू एम

जवाबों:


167

अधिकतम 255 वर्णों के साथ, DBMS फ़ील्ड में डेटा की लंबाई को इंगित करने के लिए एक बाइट का उपयोग करने का विकल्प चुन सकता है। यदि सीमा 256 या अधिक थी, तो दो बाइट्स की आवश्यकता होगी।

लंबाई शून्य का मान निश्चित रूप से varcharडेटा के लिए मान्य है (जब तक कि अन्यथा विवश न हो)। अधिकांश सिस्टम ऐसे खाली स्ट्रिंग को NULL से अलग मानते हैं, लेकिन कुछ सिस्टम (विशेष रूप से Oracle) खाली स्ट्रिंग को NULL के समान पहचानते हैं। उन प्रणालियों के लिए जहां खाली स्ट्रिंग NULL नहीं है, पंक्ति में कहीं अतिरिक्त बिट यह इंगित करने के लिए आवश्यक होगा कि मान को NULL माना जाना चाहिए या नहीं।

जैसा कि आप ध्यान दें, यह एक ऐतिहासिक अनुकूलन है और संभवतः आज अधिकांश प्रणालियों के लिए प्रासंगिक नहीं है।


लंबाई के लिए एक बाइट का आकार देना समझ में आता है, लेकिन WRT आपके दूसरे पैराग्राफ का है, संभवत: लंबाई शून्य का / मान / मान्य है, लेकिन लंबाई शून्य का / / क्षमता है?
एंड्रयू एम

1
@Andrew: मैंने अभी कोशिश की और PostgreSQL को खारिज कर दिया varchar(0)। यह शायद उतना उपयोगी नहीं है क्योंकि मूल्य केवल दो चीजें हो सकती हैं, रिक्त स्ट्रिंग या NULL, और इसलिए आप बस इसके लिए उपयोग कर सकते हैं bit
ग्रेग हेविगिल

तो क्या यह मान लेना सही है कि क्षमता मेटाडेटा डेटा के रूप में उसी सन्निहित ब्लॉक में संग्रहीत किया जाता है, और इसलिए DB के लिए एक पृष्ठ के भीतर उन दो चीजों (डेटा और मेटाडेटा) की कुल रखने के लिए एक फायदा है (अनुमानतः 256) बाइट्स)?
एंड्रयू एम

@ भारत: यह एक धारणा है जो प्रश्न में DBMS के कार्यान्वयन विवरण के आधार पर सही हो सकती है या नहीं भी हो सकती है। पृष्ठ आकार आमतौर पर 256 बाइट्स से बहुत बड़ा होता है। जैसा कि मैंने उल्लेख किया है, इस प्रकार का अनुकूलन कभी-कभी महत्वपूर्ण होता है (जैसे कि यदि आप अरबों छोटी पंक्तियों को संग्रहीत कर रहे हैं), लेकिन अधिकांश समय यह चिंता करने योग्य नहीं है।
ग्रेग हेविगिल

3
डिस्क स्पेस (और इंडेक्स स्पेस) में महत्व इसलिए नहीं है क्योंकि एक पेज में 256 फिट हो सकते हैं, लेकिन क्योंकि 1 बाइट बनाम 2 बाइट्स (लाखों / अरबों / खरबों की पंक्तियों के लिए) एक बड़ा अंतर रखती है।
ypercube y

35

255 mySQL4 और पूर्व में varchar सीमा थी।

इसके अलावा 255 वर्ण + अशक्त टर्मिनेटर = 256

या 1 बाइट लंबाई विवरणक एक संभावित सीमा 0-255 वर्ण देता है


और पढ़ना char foo[256]महत्वपूर्ण है क्योंकि मेमोरी प्रबंधन को 2 की शक्तियां पसंद हैं। देखें: stackoverflow.com/questions/3190146/… आवंटन char foo[257]या तो मेमोरी को विखंडित करेगा या 512 बाइट्स ले जाएगा।
ebyrob

4
क्या varchar स्ट्रिंग की लंबाई को स्टोर नहीं करता है, और इसलिए एक शून्य टर्मिनेटर की आवश्यकता नहीं है?
क्रंचर

19

255 सबसे बड़ा संख्यात्मक मान है जिसे एकल-बाइट अहस्ताक्षरित पूर्णांक (8-बिट बाइट्स मानते हुए) में संग्रहीत किया जा सकता है - इसलिए, किसी उद्देश्य के लिए एक स्ट्रिंग की लंबाई को स्टोर करने वाले अनुप्रयोग 255 से अधिक 256 को पसंद करेंगे क्योंकि इसका मतलब है कि उन्हें केवल "आकार" चर के लिए 1 बाइट आवंटित करें।


17

MySQL मैनुअल से:

डेटा प्रकार:
VARCHAR (एम), वार्बिनरी (एम)

संग्रहण आवश्यक:
L + 1 बाइट्स यदि स्तंभ मानों की आवश्यकता होती है 0 - 255 बाइट्स, L + 2 बाइट्स यदि मानों के लिए 255 बाइट्स की आवश्यकता हो सकती है

समझें और चुनाव करें।


हां, लेकिन M represents the declared column length in characters for nonbinary string types and bytes for binary string types. L represents the actual length in bytes of a given string value. dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
DLight


7

255 की अधिकतम लंबाई डेटाबेस इंजन को प्रत्येक क्षेत्र की लंबाई को स्टोर करने के लिए केवल 1 बाइट का उपयोग करने की अनुमति देता है। आप सही हैं कि अंतरिक्ष की 1 बाइट आपको स्ट्रिंग की लंबाई के लिए 2 ^ 8 = 256 अलग-अलग मूल्यों को संग्रहीत करने की अनुमति देती है।

लेकिन अगर आप फ़ील्ड को शून्य-लंबाई वाले टेक्स्ट स्ट्रिंग्स को संग्रहीत करने की अनुमति देते हैं, तो आपको लंबाई में शून्य स्टोर करने में सक्षम होने की आवश्यकता है। तो आप 256 अलग-अलग लंबाई मानों की अनुमति दे सकते हैं, जो शून्य से शुरू होता है: 0-255।


6

अक्सर varchars को पास्कल स्ट्रिंग्स के रूप में लागू किया जाता है: बाइट # 0 में वास्तविक लंबाई को पकड़े हुए। लंबाई इसलिए 255 से बंधी थी। (एक बाइट का मूल्य 0 से 255 तक भिन्न होता है।)


5

<<

बिट्स / बाइट्स भंडारण के मूल सिद्धांतों को याद किया, यह 256 और 65536 के बीच किसी भी पूर्णांक के लिए पूर्णांक को 256 से नीचे और दो बाइट को स्टोर करने के लिए आवश्यक है। इसलिए, इसे 511 या 512 स्टोर करने के लिए एक ही स्थान (दो बाइट) या 65535 की आवश्यकता होती है .... इस प्रकार यह स्पष्ट है कि उपर्युक्त चर्चा में उल्लिखित यह तर्क N / A के लिए varchar (512) या varchar (511) है।


4

8 बिट्स अहस्ताक्षरित = 256 बाइट्स

255 वर्ण + बाइट 0 लंबाई के लिए


3

यह ऐसा हुआ करता था कि सभी तारों को एक एनयूएल टर्मिनेटर, या "बैकस्लैश-शून्य" की आवश्यकता होती थी। अपडेट किए गए डेटाबेस में ऐसा नहीं है। यह "255 वर्णों का पाठ" था एक "\ 0" के साथ स्वचालित रूप से अंत में जोड़ा गया ताकि सिस्टम को पता चले कि स्ट्रिंग कहाँ समाप्त हुई। अगर आपने VARCHAR (256) कहा, तो यह 257 तक समाप्त हो जाएगा और फिर आप एक वर्ण के लिए अगले रजिस्टर में होंगे। बेकार। इसलिए सब कुछ VARCHAR (255) और VARCHAR (31) था। आदत से 255 लगता है कि चारों ओर अटक गया है, लेकिन 31 का 32 और 511 का 512 बन गया है। वह हिस्सा अजीब है। खुद को VARCHAR (256) लिखना कठिन है।


0

मुझे लगता है कि यह आपके सवाल का जवाब दे सकता है। ऐसा लगता है कि यह पहले के सिस्टम में varchar की अधिकतम सीमा थी। मैंने इसे एक और स्टैकओवरफ़्लो प्रश्न से हटा दिया।

यह जानना मुश्किल है कि सबसे लंबा डाक पता क्या है, बेशक, यही वजह है कि बहुत से लोग एक लंबा VARCHAR चुनते हैं जो निश्चित रूप से किसी भी पते से अधिक लंबा है। और 255 प्रथागत है क्योंकि हो सकता है कि यह कुछ डेटाबेस में VARCHAR की अधिकतम लंबाई समय के साथ (साथ ही साथ PostgreSQL हाल ही में तक) हो।

क्या सभी पाठ-आधारित क्षेत्रों के लिए जेनेरिक varchar (255) का उपयोग करने के नुकसान हैं?


0

डेटा को बाइनरी सिस्टम में मेमोरी में सहेजा जाता है और 0 और 1 बाइनरी अंक होते हैं। सबसे बड़ी बाइनरी संख्या जो 1 बाइट (8-बिट) में फिट हो सकती है 11111111 है जो दशमलव 255 में परिवर्तित होती है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.