MySQL: VARCHAR (255) के बजाय VARCHAR (20) का उपयोग क्यों करें?

Question

संभव डुप्लिकेट:
Are there disadvantages to using a generic varchar(255) for all text-based fields?

MySQL में आप VARCHAR फ़ील्ड प्रकार के लिए लंबाई चुन सकते हैं। संभावित मान 1-255 हैं।

लेकिन यदि आप VARCHAR (205) के बजाय अधिकतम VARCHAR (255) का उपयोग करते हैं तो इसका क्या फायदे हैं? जहां तक ​​मुझे पता है, प्रविष्टियों का आकार केवल सम्मिलित स्ट्रिंग की वास्तविक लंबाई पर निर्भर करता है।

आकार (बाइट्स) = लंबाई + 1

तो अगर आप एक VARCHAR (255) क्षेत्र में शब्द "उदाहरण" है, यह 8 बाइट्स होगा। यदि आपके पास VARCHAR (20) फ़ील्ड में है, तो इसमें 8 बाइट भी होंगे। अंतर क्या है?

मुझे आशा है कि आप मेरी मदद कर सकते हैं। अग्रिम में धन्यवाद!

Answer 1

की जाँच करें: Reference for Varchar

संक्षेप में वहाँ बहुत अंतर जब तक आप अपने VARCHAR में 255 के आकार जो लंबाई उपसर्ग के लिए एक और बाइट की आवश्यकता होगी से अधिक नहीं है।

लंबाई किसी अन्य चीज़ की तुलना में कॉलम में संग्रहीत डेटा पर एक बाधा का संकेत देती है। यह मूल रूप से कॉलम के लिए अधिकतम संग्रहण आकार को भी सीमित करता है। आईएमएचओ, डेटा के संबंध में लंबाई को समझना चाहिए। यदि आपका सोशल सिक्योरिटी स्टोर करना # यह लंबाई को 128 तक सेट करने का कोई मतलब नहीं है, भले ही आपको स्टोरेज में कुछ भी खर्च न हो, यदि आप वास्तव में स्टोर करते हैं तो एसएसएन है।

Answer 2

अच्छा, अगर आप बड़ी प्रविष्टि की अनुमति देना चाहते हैं, या शायद प्रवेश आकार को सीमित कर सकते हैं।

उदाहरण के लिए, आपके पास पहले_नाम VARCHAR 20 के रूप में हो सकता है, लेकिन शायद 20 से VARCHAR 50 के रूप में street_address पर्याप्त स्थान नहीं हो सकता है। साथ ही, आप यह नियंत्रित करना चाहेंगे कि वह मान कितना बड़ा हो सकता है।

दूसरे शब्दों में, आपने तालिका को रोकने के लिए सिद्धांत में (और संभावित रूप से इंडेक्स/इंडेक्स प्रविष्टियों) को रोकने के लिए सिद्धांत में एक विशेष मूल्य कितना बड़ा हो सकता है, इसकी एक छत निर्धारित की है।

तुम बस CHAR जो एक निश्चित चौड़ाई के रूप में अच्छी तरह से है इस्तेमाल कर सकते हैं, लेकिन VARCHAR विपरीत छोटा हो सकता है, CHAR मूल्यों पैड (हालांकि यह जल्दी एसक्यूएल उपयोग करने के लिए बनाता है।

Answer 3

एक डेटाबेस परिप्रेक्ष्य प्रदर्शन से बुद्धिमान मैं करता हूँ विश्वास नहीं है कि एक अंतर होने जा रहा है।

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

Answer 4

अधिकतम अधिकतम से अधिक मूल्य चुनने के कई वैध कारण हैं ई प्रदर्शन से संबंधित नहीं है। आकार निर्धारित करना आपके द्वारा संग्रहीत डेटा के प्रकार को इंगित करने में सहायता करता है और यह सत्यापन के अंतिम-गैस प्रकार के रूप में भी कार्य कर सकता है।

उदाहरण के लिए, यदि आप यूके पोस्टकोड संग्रहीत कर रहे हैं तो आपको केवल 8 वर्णों की आवश्यकता है। इस सीमा को सेट करने से आपके द्वारा संग्रहीत डेटा के प्रकार को स्पष्ट करने में मदद मिलती है। यदि आपने 255 वर्णों का चयन किया है तो यह केवल मामलों को भ्रमित करेगा।

Answer 5

एक अर्थपूर्ण अंतर है (और मुझे विश्वास है कि यह एकमात्र अंतर है): यदि आप 30 गैर-स्पेस वर्णों को वर्चर (20) में भरने का प्रयास करते हैं, तो यह एक त्रुटि उत्पन्न करेगा, जबकि यह वर्चर (255) के लिए सफल होगा । तो यह मुख्य रूप से एक अतिरिक्त बाधा है।

Answer 6

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

पंक्ति आकार सीमाओं पर विचार करने के लिए अपनी डेटाबेस संरचना को डिजाइन करना कहीं बेहतर है।

इसके अतिरिक्त हां, आप नहीं चाहते हैं कि लोग उस क्षेत्र में 200 अक्षर डालें जहां अधिकतम मान 10 होना चाहिए। यदि वे करते हैं, तो यह लगभग हमेशा खराब डेटा होता है।

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

उनके पास डेटाबेस के लिए कोई शब्द नहीं है, जिसमें डेटा अखंडता नहीं है - बेकार।