Varchar (8000) को सेट करने के परिणाम क्या हैं?

22

चूंकि varchar क्षेत्र के आकार के लिए आनुपातिक डिस्क स्थान लेता है, तो क्या कोई कारण है कि हम हमेशा varchar को अधिकतम, जैसे varchar(8000)SQL सर्वर पर परिभाषित नहीं करें ?

टेबल बनाने पर, अगर मैं किसी को भी करते हुए देखूं तो मुझे varchar(100)उनसे कहना चाहिए कि आप गलत नहीं हैं, आपको क्या करना चाहिए varchar(8000)?

sql-server varchar

— अलेक्सांद्र लेवचुक
स्रोत

मुझे लगता है कि हमें तालिका बनाने में उपयोग और संग्रहीत प्रक्रियाओं के पैरामीटर घोषणाओं में उपयोग के बीच अंतर करना होगा। दूसरी व्याख्या के लिए मेरा प्रश्न देखें dba.stackexchange.com/questions/1772/…

— bernd_k

18

लंबाई डेटा पर एक बाधा है (जैसे कि चेक, एफके, नल आदि)
प्रदर्शन जब पंक्ति 8060 बाइट्स से अधिक होती है
अद्वितीय बाधा या सूचकांक नहीं हो सकता (कुंजी स्तंभ की चौड़ाई <900 होनी चाहिए)
डिफ़ॉल्ट SET ANSI PADDING ON है = बहुत सारे अनुगामी रिक्त स्थान संग्रहीत होने की संभावना है
SQL सर्वर मान लेगा औसत लंबाई 4000 तरह के ऑपरेशन के लिए है, इसके आधार पर मेमोरी आवंटित करना (इसे वापस करने के लिए एक लिंक खोजने की आवश्यकता है लेकिन मुझे ऐसा करते समय मुझे जंग करना :-)

सारांश: यह मत करो

— GBN
स्रोत

प्रदर्शन जब पंक्ति 8060 बाइट्स से अधिक होती है । यह वास्तविक प्रयुक्त बाइट्स को संदर्भित करता है और अनुमत बाइट्स को अधिकतम करने के लिए नहीं?

— bernd_k

@bernd_k: 8060 = एक पंक्ति के लिए सबसे बड़ी मात्रा में डेटा जो एक एकल 8192 पृष्ठ में फिट होगा। पंक्ति उपरि शामिल करें। रेमिनेडर (132 बाइट्स) = पेज ओवरहेड

— gbn

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

— bernd_k

@bernd_k: किसी भी प्रदर्शन में कमी 1. प्रकारों के लिए मेमोरी आवंटन के कारण होती है 2. पंक्ति अतिप्रवाह (> 8060 बाइट्स)। प्रत्येक चरचर (8000) में 10 वर्ण होने का तथ्य तब तक अप्रासंगिक है जब तक कि ये शर्तें पूरी नहीं हो जाती हैं (एसक्यूएल कुंजी के बारे में बाद में संभावित त्रुटियों के बारे में चेतावनी देगा)

— gbn

क्या किसी अन्य प्रश्न के लिए 100 बाइट की लंबाई वाले खेतों में एक वर्चर (100) कॉलम के साथ एक टेबल को छाँटना है, क्योंकि सॉर्टिंग औसतन 50 वर्ण मानती है?

— 18 अक्टूबर को bernd_k

7

मान लें कि आप SQL सर्वर का जिक्र कर रहे हैं, तो मैं एक के बारे में सोच सकता हूं।

तालिका में एक पंक्ति के आकार (8K) की एक सीमा होती है और SQL आपको चर क्षेत्रों को परिभाषित करने देता है जो सैद्धांतिक रूप से उस सीमा से अधिक हो सकते हैं। यदि वे संबंधित क्षेत्र में बहुत अधिक डेटा डालते हैं, तो उपयोगकर्ता को त्रुटियाँ मिल सकती हैं।

SQL 2K8 से शुरू करके आप इस सीमा को पार कर सकते हैं, लेकिन प्रदर्शन निहितार्थ हैं ।

इसके अलावा, आकार को सीमित करने की पूरी तर्कशीलता जांच है कि आप डेटा को देखने के लिए क्या उम्मीद करते हैं। यदि आप एक अनबाउंड लंबाई क्षेत्र चाहते हैं तो पाठ या पाठ के साथ क्यों नहीं जाना चाहिए?

— JohnFx
स्रोत

तो पाठ और ntext डेटा प्रकार एक तरह से संग्रहीत होते हैं जो प्रदर्शन को प्रभावित नहीं करते हैं?

— चाड

उन प्रकारों का तालिका में 8K पंक्ति आकार सीमा में उतना योगदान नहीं है क्योंकि वास्तविक डेटा को स्तंभों के बाकी हिस्सों के साथ इनलाइन के बजाय कवर के नीचे एक अलग तालिका में संग्रहीत किया जाता है। अभी भी एक प्रदर्शन प्रभाव है, लेकिन विभिन्न कारणों से। इन क्षेत्रों पर फ़ीचर सपोर्ट की सीमाएँ भी हैं, जब

— वर्कर

पाठ और ntext को varchar (max) के पक्ष में चित्रित किया गया है।

— फिल हेल्मर

3

निश्चित रूप से यह इस बात पर निर्भर करता है कि क्षेत्र में क्या जानकारी संग्रहीत की जा रही है?

कुछ चीजों में कई कारणों से अधिकतम लंबाई होने वाली है और यदि अधिकतम लंबाई होनी है तो आपके क्षेत्र की लंबाई होनी चाहिए।

यदि सैद्धांतिक रूप से कोई अधिकतम लंबाई नहीं है, तो मैं सवाल करूंगा कि वर्चर का उपयोग क्यों किया जाएगा।

— टोबी
स्रोत

3

मैं Oracle डेटाबेस के संदर्भ में मैंने सीखा है कि हमेशा डेटाबेस कॉलम के लिए सबसे छोटे क्षेत्र के आकार का उपयोग करने से एक नुकसान होता है।

जब एक डेटाबेस से इम्पोर्ट एक्सपोर्ट के जरिए डेटा को सिंगल बाइट कोलैटेशन के साथ एक से कई बाइट कोलैबरेशन के साथ (जैसे कि Oracle XE) बाइट्स में लंबाई बढ़ जाती है और इम्पोर्ट फेल द्वारा बनाए गए टेबल में डेटा इम्पोर्ट कर सकते हैं। बेशक Oracle के पास varchar2 लंबाई को या तो चार या बाइट के रूप में परिभाषित करने का विकल्प है।

यहाँ मेरा कहना यह है कि, फील्ड को हमेशा जितना संभव हो उतना छोटा परिभाषित करना बुद्धिमानी नहीं है। मैंने बाद में फ़ील्ड को बढ़ाने के लिए बहुत अधिक परिवर्तन तालिकाओं को देखा है (परिवर्तित आवश्यकताओं के कारण)।

20% होने के साथ - 100% अप्रयुक्त क्षेत्र यहाँ एक चर्चा का विकल्प है।

— bernd_k
स्रोत