वर्चर (100) वर्चर (100)

Question

से बेहतर है। क्या यह डेटा भंडारण के बिंदु से मायने रखता है यदि मैं दशमलव फ़ील्ड सीमा या हेक्साडेसिमल का उपयोग करूंगा (10,20,50 के बजाय 16,32,64 कहें)?

मैं पूछता हूं क्योंकि मुझे आश्चर्य है कि अगर एचडीडी पर क्लस्टर के साथ इसका कोई संबंध नहीं होगा?

धन्यवाद!

Answer 1

VARCHAR (128) VARCHAR (100) से बेहतर है यदि आपको 100 बाइट्स से अधिक तारों को स्टोर करने की आवश्यकता है।

अन्यथा, उनके बीच चयन करने के लिए बहुत कम है; आपको वह विकल्प चुनना चाहिए जो उस डेटा की अधिकतम लंबाई को बेहतर ढंग से फिट करे जो आपको स्टोर करने की आवश्यकता हो। आप उनके बीच प्रदर्शन अंतर को मापने में सक्षम नहीं होंगे। बाकी सब कुछ, डीबीएमएस शायद आपके द्वारा भेजे गए डेटा को केवल स्टोर करता है, इसलिए यदि आपकी औसत स्ट्रिंग है, तो 16 बाइट्स कहें, यह केवल 16 (या, अधिक संभावना, 17 - लंबाई को संग्रहित करने के लिए 1 बाइट की अनुमति देगी) डिस्क पर बाइट्स का उपयोग करेगा । बड़ा आकार किसी पृष्ठ पर कितनी पंक्तियां फिट हो सकता है इसकी गणना को प्रभावित कर सकता है - हानिकारक रूप से। तो सबसे छोटा आकार चुनना जो पर्याप्त है समझ में आता है - अपशिष्ट नहीं, नहीं चाहते हैं।

तो संक्षेप में, प्रदर्शन या डिस्क उपयोग के मामले में दोनों के बीच कीमती अंतर है, और सुविधाजनक बाइनरी सीमाओं के साथ संरेखित करने से वास्तव में कोई फर्क नहीं पड़ता है।

Answer 2

हाँ, लेकिन यह इतना आसान नहीं है। कभी-कभी 128 100 से बेहतर हो सकता है और कभी-कभी, यह दूसरी तरफ है।

तो क्या चल रहा है? varchar केवल आवश्यकतानुसार स्थान आवंटित करता है ताकि यदि आप को varchar(100) में संग्रहीत करते हैं तो यह varchar(128) में बिल्कुल उसी स्थान की जगह लेगा।

सवाल यह है कि: यदि आप पंक्तियों को भरते हैं, तो क्या आप "ब्लॉक" सीमा/सीमा पर क्लिक करेंगे या नहीं?

डेटाबेस अपने डेटा को ब्लॉक में संग्रहीत करते हैं। इनके पास एक निश्चित आकार है, उदाहरण के लिए 512 (यह मान कुछ डेटाबेस के लिए कॉन्फ़िगर किया जा सकता है)। तो सवाल यह है कि प्रत्येक पंक्ति को लाने के लिए डीबी को कितने ब्लॉक पढ़ना पड़ता है? कई ब्लॉकों की अवधि वाली पंक्तियों को अधिक I/O की आवश्यकता होगी, इसलिए इससे आपको धीमा कर दिया जाएगा।

लेकिन फिर से: यह कॉलम के सैद्धांतिक अधिकतम आकार पर निर्भर नहीं है लेकिन ए) आपके पास कितने कॉलम हैं (प्रत्येक स्तंभ को खाली होने पर भी थोड़ी सी जगह की आवश्यकता होती है या null), बी) कितने आपके पास निश्चित चौड़ाई कॉलम हैं (number/decimal, char), और अंततः सी) चरम कॉलम में आपके पास कितना डेटा है।

Answer 3

यदि यह एक सी-प्रोग्राम होगा तो मैं इसके बारे में सोचने के लिए कुछ समय व्यतीत करूंगा। लेकिन डेटाबेस के साथ मैं इसे डीबी इंजन में छोड़ दूंगा।

डीबी प्रोग्रामर ने सर्वश्रेष्ठ मेमोरी लेआउट के बारे में सोचने में काफी समय बिताया है, इसलिए बस डेटाबेस को बताएं कि आपको क्या चाहिए और यह डेटा को इस तरह से स्टोर करेगा जो डीबी इंजन को सर्वोत्तम (आमतौर पर) उपयुक्त बनाता है। कैसे स्ट्रिंग संग्रहीत किया जाता है:

हैं आप अपने डेटा संरेखित करने के लिए चाहते हैं, आप आंतरिक डेटा संगठन के सटीक ज्ञान की आवश्यकता होगी? लम्बाई स्टोर करने के लिए एक, दो या 4 बाइट? क्या यह सादा बाइट अनुक्रम के रूप में संग्रहीत है या यूटीएफ -8 यूटीएफ -16 यूटीएफ -32 में एन्कोड किया गया है? क्या डीबी को नल या> MAXINT मानों की पहचान करने के लिए अतिरिक्त बाइट की आवश्यकता है? हो सकता है कि स्ट्रिंग को एक एनयूएल-समाप्त बाइट अनुक्रम के रूप में संग्रहीत किया जाता है - फिर एक बाइट को आंतरिक रूप से आवश्यक है।

साथ ही वर्चर के साथ यह भी सत्य नहीं है, कि डीबी हमेशा आपकी स्ट्रिंग के लिए 100 (128) बाइट आवंटित करेगा। हो सकता है कि यह केवल एक सूचक को संग्रहीत करे जहां वास्तविक डेटा के लिए जगह है।

तो अगर मैं आपकी आवश्यकता है तो मैं दृढ़ता से VARCHAR (100) का उपयोग करने का सुझाव दूंगा। यदि डीबी इसे संरेखित करने का फैसला करता है तो किसी भी तरह से अतिरिक्त आंतरिक डेटा के लिए भी जगह है।

अन्य तरीकों से: मान लें कि आप VARCHAR (128) का उपयोग करते हैं और सभी चीजें एक साथ आती हैं: डीबी आपके डेटा के लिए 128 बाइट आवंटित करता है। इसके अतिरिक्त इसे वास्तविक स्ट्रिंग लंबाई को स्टोर करने के लिए 2 बाइट्स की आवश्यकता होती है - 130 बाइट बनाता है - और फिर यह हो सकता है कि डीबी डेटा को अगले संरेखित करे (चलो 32 बाइट कहें) सीमा: डिस्क पर आवश्यक वास्तविक डेटा अब 160 बाइट्स है 8-}