SqlServer और nvarchar (अधिकतम)

Question

हम वर्तमान में स्ट्रिंग को स्टोर करने के लिए डेटाबेस में पर्याप्त जगह नहीं होने पर किसी भी समस्या को रोकने के लिए विशिष्ट लंबाई निर्दिष्ट करने के बजाय हमारे स्ट्रिंग कॉलम को nvarchar(max) पर सेट करने के लिए देख रहे हैं। मैं बस सोच रहा हूं कि यह एक अच्छी बात है या इससे कोई समस्या हो सकती है क्योंकि ऐसा करना ठीक था, तो की लंबाई nvarchar(max) की बजाय निर्दिष्ट क्यों करें। हम varbinary(max) का भी बहुत उपयोग करते हैं क्योंकि हम नहीं जानते कि हमें कितना द्विआधारी डेटा चाहिए, इसलिए मुझे यकीन नहीं है कि यह कितना प्रभाव है या तो यह बताएं कि हमारे आवेषण उतना तेज़ नहीं हैं जितना मुझे लगता है कि वे होना चाहिए। यह एक उदाहरण तालिका है:

CREATE TABLE [dbo].[SAMPLETABLE] ( 
[ID] [uniqueidentifier] NOT NULL, 
[FIELD1] [int] NOT NULL, 
[FIELD2] [nvarchar] (2000) NULL, 
[FIELD3] [nvarchar] (max) NULL, 
[FIELD4] [uniqueidentifier] NULL, 
[FIELD5] [int] NULL, 
[FIELD6] [nvarchar] (2000) NULL, 
[FIELD7] [varbinary] (max) NULL, 
[FIELD8] [varbinary] (max) NULL, 
[FIELD9] [varbinary] (max) NULL, 
[FIELD10] [uniqueidentifier] NULL, 
[FIELD11] [nvarchar] (2000) NULL, 
[FIELD12] [varbinary] (max) NULL, 
[FIELD13] [varbinary] (max) NULL, 
[FIELD14] [bit] NULL, 
[FIELD15] [uniqueidentifier] NULL, 
[FIELD16] [varbinary] (max) NULL, 
[FIELD17] [bit] NULL, 
[FIELD18] [tinyint] NULL, 
[FIELD19] [datetime] NULL, 
[FIELD20] [nvarchar] (2000) NULL, 
PRIMARY KEY CLUSTERED 
( 
    [ID] ASC 
) 
) ON [PRIMARY] 

GO 

ऐसे ही एक टेबल डिजाइन और बदलते nvarchar(2000)nvarchar(max) लिए है कि चीजें किसी भी बदतर (या बेहतर) होगा यह देखते हुए? क्या इस तरह के डिजाइन पर sqlserver फहरा हुआ है?

Answer 1

यदि आप जे। रैंडम डेवलपर के लिए खुश हैं, तो लाइन के नीचे 6 महीने, शेक्सपियर द्वारा प्रत्येक कॉलम में एक काम डालने के लिए, ठीक है।

मेरे लिए, डेटा मॉडलिंग का एक बड़ा हिस्सा गंभीरता से सोच रहा है कि मैं प्रत्येक कॉलम में किस डेटा को अनुमति देना चाहता हूं, और कौन सा डेटा मैं प्रतिबंधित करना चाहता हूं। इसके बाद मैं उन प्रतिबंधों को प्राप्त करने के लिए उपयुक्त CHECK बाधाओं को लागू करता हूं (जैसा कि सर्वश्रेष्ठ SQL सर्वर अनुमति देता है)। एक "समझदार" उपलब्ध एक समझदार लंबाई जांच हमेशा एक बोनस की तरह लग रहा है।

---

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

Answer 2

उत्तर "मैं एक संख्या निर्दिष्ट करने की आवश्यकता क्यों है जब मैं सभी संख्याओं को तारों के रूप में स्टोर कर सकता हूं?" - क्योंकि यह सहायक है:

• गति की दक्षता।
• भंडारण की दक्षता।
• लेखक/वास्तुकार का इरादा।
• डेटा त्रुटि पर कटौती करता है, क्योंकि केवल एक निश्चित प्रकार का डेटा फिट होगा।

लेकिन यह तुरंत किसी भी "समस्या" का कारण नहीं बनता क्योंकि nvarchar (10) nvarchar (अधिकतम) का एक उप-समूह है।

Answer 3

चलो आशा है कि आप खोज के लिए स्तंभ का उपयोग नहीं करते या अद्वितीय मान हैं ...

इंडेक्स बाइट्स 900 से अधिक विस्तृत तो आप शायद कभी नहीं एक सूचकांक बना सकते हैं नहीं हो सकता। यह एक नकारात्मक पक्ष यह है: क्योंकि यह

• वास्तव में बुरा खोज प्रदर्शन
• कोई अद्वितीय की कमी
देता

यह चारों ओर एक गणना स्तंभ के साथ काम किया जा सकता है, लेकिन फिर क्या तुम क्यों की दुकान नहीं जरूरत?

Answer 4

इन-पंक्ति प्रकारों से बीएलओबी प्रकारों में स्विच करना हमेशा एक बड़ा निर्णय होता है।आप भली कि ब्लॉब प्रकार (VARCHAR(MAX), NVARCHAR(MAX) और VARBINARY(MAX)) में पंक्ति प्रकार से एक पूरी तरह से अलग प्रकार आंतरिक रूप से हैं:

• वे एक अलग आवंटन इकाई में जाते हैं, को देखने के Table and Index Organization
• वे नहीं किया जा सकता अनुक्रमित
• sp_tableoption
• वे एक पूरी तरह से अलग से निपटने कोड पथ का उपयोग में अलग भंडारण विकल्प के अधीन हैं, को देखने के Performance comparison of varchar(max) vs. varchar(N)
• ऑनलाइन सेशन बीएलओबी के साथ तालिकाओं पर इरेशन की अनुमति नहीं है (ALTER INDEX ... REBUILD ... WITH (ONLINE= ON) पर अपवाद देखें। लगता है कि के बाद से अपनी मेज पहले से ही BLOBs है, यह कोई मुद्दा

तो ब्लॉब प्रकार के सभी स्तंभों स्विचिंग साइड इफेक्ट का एक बहुत में लाने हो सकता है आप नहीं पर विचार किया है नहीं होगा: ब्लॉब स्तंभों सूचकांक करने के लिए असंभव, कमी ऑनलाइन संचालन, बीएलओबी अंतर्निहित धीमी कोड इत्यादि के कारण सामान्य प्रदर्शन गिरावट सबसे गंभीर बाधा यह तथ्य हो सकती है कि आप उन्हें बीएलओबी बनाने के बाद कॉलम इंडेक्स करने में सक्षम नहीं होंगे। यदि यह शो स्टॉपर नहीं है, तो आपको प्रदर्शन प्रभाव का परीक्षण और माप करना होगा।

डेटा मॉडलिंग चिंताओं अन्य उठाया है सामान्य रूप में मान्य हैं, लेकिन मैं समझता हूँ कि अक्सर असली दुनिया में सिद्धांत केवल सिद्धांत में काम करता है ...

Answer 5

यहाँ एक ही जवाब मैं एक पुरुष जो चाहता था को दे दिया है अनंत टेबल:

Database alternative to MySQL made for millions of TABLES

कि ऊपर थोड़ा किसी भी संबंधपरक डेटा भंडारण के लिए एक इष्टतम से कम डिजाइन है। पॉप डेटा के लिए वीज़ल चला जाता है: बस एक चुनें जिसे आप चाहते हैं कि डेटा प्राप्त हो।

शायद कोई एसक्यूएल समाधान बेहतर काम करेगा ताकि आपके पास गतिशील डेटा हो और कॉलम सीमाओं के बारे में चिंता न हो।

मुझे लगता है कि अगर हम सवालों के जवाब देने जा रहे हैं तो मुझे यह भी लगता है कि यह खराब डिजाइन के विकल्प होने पर सर्वोत्तम/बेहतर प्रथाओं की पेशकश करने के लिए हमें व्यवहार करता है। पुरुष आप के बाद आने की

लगता है कि के.एम. मेरे अनुभव में

Answer 6

ऊपर कहा नहीं कई 2000 वर्ण लंबा क्षेत्रों अंत हालांकि अनुक्रमित। मुझे लगता है कि कुछ arbitary लंबाई की तुलना में nvarchar (अधिकतम) का उपयोग करना बेहतर है कि यदि डेटा पर्याप्त नहीं है तो आपको डेटा को छोटा करना पड़ सकता है।

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