PostgreSQL के डॉक्स के अनुसार , कोई प्रदर्शन अंतर नहीं है VARCHAR, VARCHAR(n)और TEXT।
क्या मुझे नाम या पता कॉलम में एक मनमानी लंबाई सीमा जोड़नी चाहिए ?
संपादित करें :
मुझे पता है कि CHARप्रकार अतीत का अवशेष है और मुझे न केवल प्रदर्शन में दिलचस्पी है, बल्कि अन्य पेशेवरों और विपक्षों जैसे इरविन ने अपने अद्भुत जवाब में कहा है।
जवाबों:
जवाब है नहीं । यदि आप इससे बच सकते हैं तो
लंबाई संशोधक न जोड़ें varchar। अधिकांश समय, आपको वास्तव में वैसे भी लंबाई प्रतिबंध की आवश्यकता नहीं होती है। बस textसभी चरित्र डेटा के लिए उपयोग करें । varcharअगर आपको RDBMS के साथ संगत रहने की आवश्यकता नहीं है, तो इसे (कोई लंबाई संशोधक) न बनाएं text।
प्रदर्शन लगभग एक ही है - textहै एक सा दुर्लभ स्थितियों में तेजी है, और आप लंबाई पर जांच करने के लिए चक्र को बचाने।
यदि आपको वास्तव में एक अधिकतम लंबाई लागू करने की आवश्यकता है, तब भी उपयोग करें textऔर उसके लिए एक चेक बाधा जोड़ें :
ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 51);आप किसी भी समय तालिका की परिभाषा और सभी वस्तुओं (विचारों, कार्यों, विदेशी कुंजी, ...) के साथ गड़बड़ किए बिना ऐसे अवरोध को संशोधित या गिरा सकते हैं।
लंबाई संशोधक के साथ आप बस में चलाने इस तरह की समस्याओं या इस या इस ...
कुछ हद तक दर्द को कम करने के लिए PostgreSQL 9.1 ने एक नई सुविधा शुरू की। मैं यहां जारी नोट्स को उद्धृत करता हूं :
ALTER TABLE ... SET DATA TYPEउपयुक्त मामलों में तालिका के पुनर्लेखन से बचने की अनुमति दें (नूह मिस, रॉबर्ट हास)उदाहरण के लिए,
varcharस्तंभ को पाठ में परिवर्तित करने के लिए अब तालिका के पुनर्लेखन की आवश्यकता नहीं है। हालांकि, एकvarcharस्तंभ पर लंबाई की बाधा को बढ़ाने के लिए अभी भी एक टेबल पुनर्लेखन की आवश्यकता है।
varchar(n)सब के बाद, सादगी के लिए - यदि डाउनसाइड्स आमतौर पर आपको प्रभावित नहीं करते हैं। ( यदि आप वास्तविक अधिकतम लंबाई लागू करना चाहते हैं, तो यह सीमा आपके मामले में मनमानी नहीं है ।)
यदि आप यह सुनिश्चित करने के लिए कि आप डेटा को मान्य करते हैं, तो एक प्रकार की चेक बाधा के रूप में लंबाई सीमा देखते हैं, तो हाँ एक जोड़ें। वास्तव में आप एक सीमा परिभाषा का उपयोग नहीं करना चाह सकते हैं, लेकिन इसके बजाय सीमा को तेजी से बदलने के लिए एक वास्तविक जांच बाधा ।
एक लंबी सीमा को बदलने (बढ़ाने) के लिए आपको दौड़ने की आवश्यकता होती है, ALTER TABLEजिसे समाप्त करने में लंबा समय लग सकता है (तालिका के संभावित फिर से लिखने के कारण) जिसके दौरान एक विशेष टेबल लॉक आवश्यक है।
एक चेक बाधा को बदलने (यानी छोड़ने और फिर से बनाने) एक बहुत ही संक्षिप्त ऑपरेशन है और केवल तालिका के डेटा को पढ़ने की आवश्यकता है, यह किसी भी पंक्तियों को नहीं बदलेगा। तो यह बहुत जल्दी होने वाला है (जिसका अर्थ है कि बहुत कम समय के लिए अनन्य टेबल लॉक आयोजित किया जाएगा)।
ऑपरेशन के दौरान ए text, varcharया varchar(5000)कॉलम के बीच कोई अंतर नहीं होता है ।
सवाल विशेष रूप से है कि क्या VARCHAR कॉलम में एक मनमाना लंबाई सीमा जोड़ दी गई है ?
उस के लिए, जवाब बस "नहीं" है। ऐसा कुछ भी नहीं है जो आप की तरह एक मनमानी सीमा को जोड़ने का औचित्य साबित कर सकता है जैसे कि अवर डेटाबेस में जो कि varchar(max)सम्मेलनों का समर्थन या उपयोग करते हैं varchar(255)। हालाँकि, अगर कल्पना एक सीमा को संबोधित करती है, तो मुझे लगता है कि उत्तर विशेष रूप से PostgreSQL के आधुनिक संस्करणों पर अधिक जटिल हो जाता है। और, उसके लिए, मैं हाँ की ओर झुकूंगा ।
मेरी राय में, सीमा एक बुद्धिमान-विकल्प है अगर कल्पना को इसकी आवश्यकता होती है। विशेष रूप से अधिक उचित कार्यभार के लिए। यदि कोई अन्य कारण नहीं है, तो मेटा-डेटा को संरक्षित करने के लिए।
यहां मेरे जवाब से, CHAR बनाम VARCHAR (पोस्टग्रेज) के लिए सूचकांक प्रदर्शन , जहां मैं मेटा-डेटा के मूल्य को संबोधित करता हूं।
अगर मुझे एक युक्ति मिली जिसमें परिवर्तनशील-लंबाई वाली पाठ-कुंजियाँ थीं, जो सार्थक थीं और मुझे भरोसा था कि एक अधिकतम अधिकतम-लंबाई है, तो मैं भी उपयोग करूँगा
varchar। हालाँकि, मैं उस मापदंड के अनुरूप कुछ भी नहीं सोच सकता।
ऐसा लगता है कि कुछ प्रदर्शन अंतर हो सकते हैं यदि VARCHARनियमित रूप से बहुत बड़े तारों को संग्रहीत करने के लिए उपयोग किया जाता है, क्योंकि "लंबे तार स्वचालित रूप से सिस्टम द्वारा संपीड़ित होते हैं" और "बहुत लंबे मान भी पृष्ठभूमि तालिकाओं में संग्रहीत होते हैं।" सैद्धांतिक रूप से इसका मतलब यह होगा कि बहुत लंबे स्ट्रिंग फ़ील्ड के लिए अनुरोधों की एक उच्च मात्रा एक छोटे स्ट्रिंग फ़ील्ड की तुलना में धीमी होगी। आप शायद इस समस्या में कभी नहीं भागेंगे, क्योंकि नाम और पते बहुत लंबे नहीं होंगे।
हालाँकि, आप अपने डेटाबेस के बाहर इन स्ट्रिंग्स का उपयोग कैसे कर रहे हैं, इसके आधार पर, आप सिस्टम के दुरुपयोग को रोकने के लिए एक व्यावहारिक सीमा जोड़ना चाहते हैं। उदाहरण के लिए, यदि आप कहीं पर नाम और पता प्रदर्शित कर रहे हैं, तो हो सकता है कि आप "नाम" फ़ील्ड में पाठ का पूरा अनुच्छेद प्रदर्शित न कर सकें, इसलिए यह नाम कॉलम को 500 जैसी किसी चीज़ तक सीमित करने के लिए समझ में आएगा। वर्ण।
VARCHARTEXTपोस्टग्रेज में विशुद्ध रूप से सिंथैटिक शुगर है , स्टोरेज हैंडलिंग में शून्य अंतर है; आपके द्वारा उल्लेख किया गया कंप्रेशन बनाम बैकग्राउंड टेबल स्टोरेज कॉलम में डेटा की वास्तविक लंबाई के आधार पर किया जाता है न कि कॉलम मेटाडेटा पर। TEXT कॉलम को varlenaC संरचना के रूप में आंतरिक रूप से संग्रहीत किया जाता है (जो कि एक वैरिएबल लंबाई वाला सरणी है, जिसमें पहले 4 बाइट्स के साथ create / update पर लंबाई को संग्रहीत किया जाता है) और यह वह संरचना है जो इसकी लंबाई के आधार पर अनुकूलित की जाती है।