यह पूरी तरह से इस्तेमाल किए जा रहे डीबीएमएस इंजन पर निर्भर करता है। SQL स्वयं यह अनिवार्य नहीं करता है कि चीज़ों को भौतिक रूप से कैसे संग्रहीत किया जाता है, ठीक वैसे ही जैसे वे तार्किक रूप से देखे जाते हैं।
उदाहरण के लिए, आपका डीबीएमएस अधिकतम आकार के लिए पंक्ति में स्थान आवंटित कर सकता है, साथ ही लंबाई को स्टोर करने के लिए कुछ अतिरिक्त बाइट्स भी आवंटित कर सकता है। उस स्थिति में, varchar(10) . के बीच एक बड़ा अंतर होगा और varchar(1000) चूंकि आप प्रति पंक्ति काफ़ी जगह बर्बाद करेंगे।
वैकल्पिक रूप से, यह varchar . के लिए बफर पूल का उपयोग कर सकता है डेटा और पंक्ति में केवल लंबाई और बफर पूल "शुरुआती पता" स्टोर करें। उस स्थिति में, प्रत्येक पंक्ति एक varchar . के लिए समान आकार की जानकारी संग्रहीत करेगी कॉलम अपने आकार की परवाह किए बिना, लेकिन उस कॉलम में वास्तविक डेटा निकालने के लिए एक अतिरिक्त चरण होगा (बफ़र पूल के लिंक के बाद)।
आपके द्वारा varchar का उपयोग करने का कारण यही कारण है कि इसका नाम varchar रखा गया है . यह आपको चर-आकार के डेटा तत्वों को संग्रहीत करने की अनुमति देता है। आमतौर पर, char(10) आपको दस अक्षर देता है, इससे कोई फर्क नहीं पड़ता, यदि आप कुछ छोटा डालते हैं तो इसे रिक्त स्थान के साथ पैडिंग करते हैं। जब आप इसे निकालते हैं तो आप पिछली जगहों को ट्रिम कर सकते हैं लेकिन यह इतना अच्छा काम नहीं करेगा यदि आप जिस डेटा को स्टोर करना चाहते हैं वह वास्तव में "hello " है , साथ एक अनुगामी स्थान जिसे आप संरक्षित रखना चाहते हैं।
एक अच्छा DBMS इंजन varchar के अधिकतम आकार के आधार पर ट्रेड-ऑफ करने का निर्णय ले सकता है कॉलम। छोटे लोगों के लिए, यह इसे पंक्ति में इनलाइन स्टोर कर सकता है और आकार के लिए अतिरिक्त बाइट्स का उपभोग कर सकता है।
लंबा varchar कॉलम को एक अलग बफर पूल में "आउटसोर्स" किया जा सकता है ताकि यह सुनिश्चित किया जा सके कि पंक्ति-पठन कुशल रखा जाए (कम से कम जब तक आपको जरूरत बड़ा varchar कॉलम, वैसे भी)।
आपको अपने विशिष्ट DBMS के लिए प्रश्न फिर से पूछने की आवश्यकता है ताकि अधिक लक्षित उत्तर प्राप्त किया जा सके।
या, पूरी ईमानदारी से, अपने डेटाबेस को केवल अधिकतम आकार को स्टोर करने के लिए इंजीनियर करें। यदि आप जानते हैं कि यह 10 है, तो varchar(1000) एक बर्बादी है। यदि, भविष्य में, आपको कॉलम को बड़ा करने की आवश्यकता है, तो वह इसे करने का समय है, अभी के बजाय (देखें YAGNI
)।
MySQL के लिए, आप Chapter 14 Storage Engines
ऑनलाइन दस्तावेज़ीकरण का।
यह विभिन्न स्टोरेज इंजन (जैसे कि InnoDB और MyISAM) को कवर करता है जो MySQL उपयोग करता है और, काफी गहराई से देखने पर, आप देख सकते हैं कि जानकारी को भौतिक रूप से कैसे संग्रहीत किया जाता है।
उदाहरण के लिए, MyISAM में, एक तालिका में चर लंबाई डेटा की उपस्थिति (varchar शामिल) का आमतौर पर अर्थ होता है डायनेमिक टेबल
. यह मोटे तौर पर ऊपर उल्लिखित बफर पूल अवधारणा के अनुरूप एक योजना का अनुसरण करता है, इस लाभ के साथ कि चर आकार के स्तंभों के लिए कम जगह बर्बाद होती है, और नुकसान यह है कि पंक्तियाँ खंडित हो सकती हैं।
अन्य भंडारण प्रारूप (संपीड़ित प्रारूप को छूट देना क्योंकि यह वास्तव में केवल-पढ़ने के लिए तालिकाओं के लिए उपयोग किया जाता है) स्थिर एक , जहां डेटा एक भौतिक पंक्ति में संग्रहीत किया जाता है।
InnoDB भौतिक संरचनाओं के बारे में जानकारी पाई जा सकती है यहाँ . इस पर निर्भर करते हुए कि आप एंटेलोप या बाराकुडा फ़ाइल प्रारूप का उपयोग करते हैं, आप "सभी जानकारी एक भौतिक पंक्ति है" या "बफर पूल" स्थिति के साथ समाप्त होते हैं, जो गतिशील और स्थिर के बीच MyISAM भेद के समान है।
