वहाँ हमेशा nvarchar (MAX) का उपयोग करने के लिए कोई नुकसान है?

342

SQL सर्वर 2005 में, क्या स्पष्ट रूप से लंबाई निर्दिष्ट करने के बजाय सभी वर्ण फ़ील्डों को nvarchar (MAX) बनाने का कोई नुकसान है, जैसे nvarchar (255)? (स्पष्ट के अलावा कि आप डेटाबेस स्तर पर क्षेत्र की लंबाई को सीमित करने में सक्षम नहीं हैं)

sql sql-server sql-server-2005

— stucampbell
स्रोत

1

मुझे समझ नहीं आ रहा है कि आप 8000+ वर्णों के नाम पर किसी को प्रवेश क्यों देना चाहते हैं।

— DForck42

2

प्रोग्रामिंग भाषाओं में एक ही तर्क लागू किया जा सकता है। हमारे सभी डेटा के लिए पुराने VB6 संस्करण पर वापस क्यों नहीं जाएं? मुझे नहीं लगता कि चेक और बैलेंस एक से अधिक जगहों पर होना जरूरी है।

— मैट स्प्रेडली

1

इसे देखें: stackoverflow.com/questions/2009694/…

— अकीरा यामामोटो

10

इस सवाल का जवाब आपका अपडेट होना चाहिए।

— जोहान

मूल लेखक ने ऐसा नहीं किया है, यह देखते हुए उत्तर-में-प्रश्न उचित उत्तर में चला गया। stackoverflow.com/a/35177895/10245 मुझे लगता है कि 7 साल पर्याप्त समय है :-)

— टिम एबेल

153

MSDN फ़ोरम पर एक ही प्रश्न पूछा गया था:

वर्चर (अधिकतम) बनाम वर्चर (255)

मूल पोस्ट से (बहुत अधिक जानकारी वहाँ):

जब आप डेटा को VARCHAR (N) कॉलम में संग्रहीत करते हैं, तो मान भौतिक रूप से उसी तरह संग्रहीत होते हैं। लेकिन जब आप इसे VARCHAR (MAX) कॉलम में स्टोर करते हैं, तो स्क्रीन के पीछे डेटा को TEXT मान के रूप में हैंडल किया जाता है। इसलिए VARCHAR (MAX) मान के साथ काम करते समय कुछ अतिरिक्त प्रसंस्करण की आवश्यकता होती है। (केवल अगर आकार 8000 से अधिक है)

VARCHAR (MAX) या NVARCHAR (MAX) को 'बड़े मूल्य प्रकार' के रूप में माना जाता है। बड़े मूल्य प्रकार आमतौर पर 'आउट ऑफ रो' संग्रहीत होते हैं। इसका अर्थ है कि डेटा पंक्ति में किसी अन्य स्थान पर एक पॉइंटर होगा जहां 'बड़ी वैल्यू' संग्रहीत है ...

— डेविड क्रेप्स
स्रोत

2

तो सवाल यह होना चाहिए कि क्या N / VARCHAR (MAX) और N / TEXT का उपयोग करने में अंतर है?

— असुरक्षित

18

यदि मुझे सही ढंग से याद है, तो क्या वे केवल पंक्ति से बाहर संग्रहीत नहीं हैं यदि आकार 8k से अधिक है?

— सैम स्कूट

79

मैंने उत्तर को "नहीं, पढ़ने का कोई नुकसान नहीं है" के रूप में पढ़ा है N/VARCHAR(MAX)क्योंकि अतिरिक्त प्रसंस्करण है "केवल अगर आकार 8000 से अधिक है"। इस प्रकार, आप केवल आवश्यक होने पर ही खर्च करते हैं , और आपका डेटाबेस कम प्रतिबंधात्मक है । क्या मैं यह गलत पढ़ रहा हूँ? लगता है कि आप लगभग हमेशा के N/VARCHAR(MAX)बजाय चाहते हैं N/VARCHAR(1-8000)...

— केंट बूगाट

1

उपरोक्त डेड लिंक - MSDN पर सवाल के लिए काम कर रहा लिंक social.msdn.microsoft.com/Forums/en-US/sqlgetstarted/thread/…

— Jagd

68

दुर्भाग्य से इस जवाब में कई समस्याएं हैं। यह 8k सीमा को एक जादुई संख्या की तरह प्रतीत होता है, यह सच नहीं है, मूल्य पंक्ति से बाहर धकेल दिया जाता है, जिसमें अधिक कारक शामिल हो सकते हैं, जिनमें शामिल हैं sp_tableoptions: msdn.microsoft.com/en-us/library/ms173530.aspx । VARCHAR (255) प्रकारों को पंक्ति से बाहर धकेला जा सकता है, उल्लेखित 'ओवरहेड' MAX और 255 के लिए समान हो सकता है। यह MAX प्रकारों की तुलना TEXT प्रकारों से करता है, जब वे अलग-अलग हो जाते हैं, जैसा कि इसे मिलता है (हेरफेर करने के लिए पूरी तरह से अलग एपीआई) विभिन्न भंडारण आदि)। यह वास्तविक अंतरों का उल्लेख करने में विफल रहता है: कोई सूचकांक नहीं, मैक्स प्रकार पर कोई ऑनलाइन संचालन नहीं

— रेमस रुसानु

50

यह एक उचित सवाल है और उन्होंने स्पष्ट ...

नुकसान में शामिल हो सकते हैं:

प्रदर्शन निहितार्थ क्वेरी ऑप्टिमाइज़र सबसे प्रभावशाली एक्सटेंशन प्लान को निर्धारित करने के लिए फ़ील्ड आकार का उपयोग करता है

9. "डेटाबेस के विस्तार और पृष्ठों में स्थान का परिवर्तन लचीला होता है। इस प्रकार अद्यतन का उपयोग करते हुए फ़ील्ड में जानकारी जोड़ते समय, आपके डेटाबेस को एक पॉइंटर बनाना होगा यदि नया डेटा पिछले सम्मिलित की तुलना में लंबा है। यह डेटाबेस फ़ाइलें। खंडित बन = लगभग सब कुछ में प्रदर्शन का स्तर गिरा नष्ट करने के लिए सूचकांक, अद्यतन और आवेषण से,। " http://sqlblogcasts.com/blogs/simons/archive/2006/02/28/Why-use-anything-but-varchar_2800_max_2900_.aspx

एकीकरण के निहितार्थ - अन्य प्रणालियों के लिए यह जानना मुश्किल है कि अपने डेटाबेस के साथ कैसे एकीकृत करें डेटा की अप्रत्याशित वृद्धि संभव सुरक्षा मुद्दों जैसे आप सभी डिस्क स्थान को ले कर एक सिस्टम को क्रैश कर सकते हैं

यहाँ अच्छा लेख है: http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1098157,00.html

— alexmac
स्रोत

4

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

— मोहतरमा

डेटाबेस द्वारा एकीकरण सबसे हास्यास्पद बात है जो मुझे पता है। यदि यह सिर्फ एक बार आयात किया जाता है तो आप LEN फ़ंक्शन द्वारा पहले डेटा की जांच कर सकते हैं।

— मैक्सिम

30

स्वीकृत उत्तर में दिए गए लिंक के आधार पर यह प्रतीत होता है कि:

किसी nvarchar(MAX)फ़ील्ड में संग्रहीत 100 वर्णों को किसी nvarchar(100)फ़ील्ड में 100 वर्णों के लिए अलग नहीं रखा जाएगा - डेटा को इनलाइन संग्रहीत किया जाएगा और आपके पास 'पंक्ति से बाहर' डेटा पढ़ने और लिखने का ओवरहेड नहीं होगा। तो वहां कोई चिंता नहीं।
यदि आकार 4000 से अधिक है, तो डेटा को स्वचालित रूप से 'आउट ऑफ रो' संग्रहीत किया जाएगा, जो कि आप चाहते हैं। तो वहाँ कोई चिंता नहीं।

तथापि...

आप किसी nvarchar(MAX)कॉलम पर एक इंडेक्स नहीं बना सकते । आप पूर्ण-पाठ अनुक्रमण का उपयोग कर सकते हैं, लेकिन आप क्वेरी प्रदर्शन को बेहतर बनाने के लिए स्तंभ पर अनुक्रमणिका नहीं बना सकते। मेरे लिए, यह सौदे को सील करता है ... यह हमेशा निवारक (मैक्स) का उपयोग करने के लिए एक निश्चित नुकसान है।

निष्कर्ष:

यदि आप अपने पूरे डेटाबेस में एक प्रकार की "सार्वभौमिक स्ट्रिंग लंबाई" चाहते हैं, जिसे अनुक्रमित किया जा सकता है और जो अंतरिक्ष और पहुंच समय बर्बाद नहीं करेगा, तो आप उपयोग कर सकते हैं nvarchar(4000)।

— टिम एबेल
स्रोत

1

यह एक मूल प्रश्न में जोड़ा गया था, जिसे उत्तर के रूप में पोस्ट किया जाना चाहिए था

— टिम एबेल

1

धन्यवाद, मेरे लिए यह अंतिम उत्तर है। मैंने अपने आप से एक ही सवाल कियाnvarchar(max)string - क्यों हर समय - जैसे C # का उपयोग न करें ? - लेकिन पॉइंट 3) (इंडेक्स इश्यू) इसका जवाब दे रहा है।

— एसक्यूएल पुलिस

1

एक एड किया। "सार्वभौमिक स्ट्रिंग लंबाई" के एक प्रकार के रूप में, आप हमेशा उपयोग कर सकते हैंnvarchar(4000)

— SQL पुलिस

@SQLGeorge मार्टिन स्मिथ द्वारा स्तंभों को व्यापक रूप से घोषित करने के प्रदर्शन के प्रभाव पर यह उत्कृष्ट उत्तर देखें

— बिलिन्क

@billinkc धन्यवाद, यह एक बेहतरीन लेख है। ठीक है, इसलिए आकार वास्तव में पूर्णता को प्रभावित करता है। मैं फिर से जवाब संपादित करूंगा।

— एसक्यूएल पुलिस

28

कभी-कभी आप चाहते हैं कि डेटा प्रकार उसमें डेटा पर कुछ अर्थ लागू करे।

उदाहरण के लिए कहें कि आपके पास एक स्तंभ है जो वास्तव में, 20 वर्णों से अधिक नहीं होना चाहिए। यदि आप उस कॉलम को VARCHAR (MAX) के रूप में परिभाषित करते हैं, तो कुछ बदमाश आवेदन इसमें एक लंबी स्ट्रिंग डाल सकते हैं और आपको कभी पता नहीं चलेगा, या इसे रोकने का कोई तरीका है।

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

— बिल कार्विन
स्रोत

9

मैं इस और कुछ अन्य टिप्पणियों से सहमत हूं, लेकिन मैं अभी भी यह सुनिश्चित करता हूं कि यह व्यवसाय स्तरीय की जिम्मेदारी है। जब तक यह डेटाबेस टियर तक पहुंचता है, तब तक इसे सलाम करना चाहिए और मूल्य को स्टोर करना चाहिए, चाहे वह कितना भी हास्यास्पद क्यों न हो। मुझे लगता है कि वास्तव में यहाँ खेलने में क्या है, मुझे लगता है कि 90% उस समय के बारे में है जब एक डेवलपर varchar (255) निर्दिष्ट करता है, उसका इरादा वास्तव में 255 वर्ण नहीं है, लेकिन कुछ अनिर्दिष्ट middling लंबाई मान है। और मेरे डीबी और अप्रत्याशित अपवादों में अनुचित रूप से बड़े मूल्यों के बीच व्यापार को देखते हुए, मैं बड़े मूल्यों को ले जाऊंगा।

— क्रिस बी।

4

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

— टॉम एच

10

लेखक के लिए उपयोगी नहीं है। उन्होंने स्पष्ट रूप से इस प्रश्न को छोड़ दिया, जिसका आपने उत्तर दिया था।

— usr

6

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

— विंस बॉड्रेन

1

यदि आपको जरूरत नहीं है या वास्तव में लंबे तार को संग्रहीत करना चाहते हैं, तो डेटा पर समझ को लागू करना बेहतर है। जैसे अगर एक पोस्टकोड फ़ील्ड को स्टोर किया जाता है, तो क्या आप किसी को सैकड़ों या हजारों वर्णों में प्रवेश करने देंगे जब यह अधिकतम 10 कहना चाहिए। - अधिकतम आकार सभी स्तरों, ग्राहक, व्यवसाय स्तरीय और डेटाबेस को मान्य किया जाना चाहिए। यदि मॉडल का प्रथम दृष्टिकोण जैसे C # और इकाई फ्रेमवर्क का उपयोग कर रहे हैं, तो आप मॉडल पर अधिकतम परिभाषित कर सकते हैं और इसे डेटाबेस, व्यावसायिक तर्क और क्लाइंट सत्यापन (jquery सत्यापन की पसंद के साथ) पर लागू कर सकते हैं। केवल नवरच (अधिकतम) का उपयोग करें यदि इसकी वास्तव में आवश्यकता हो

— पीटर केर

21

मैंने कुछ लेखों की जाँच की और इसमें से उपयोगी परीक्षण स्क्रिप्ट ढूंढी : http://www.sqlservercentral.com/Forums/Topic1480639-1292-1.aspx ने NVARCHAR (10) बनाम NVARCHAR (4000) बनाम NVARCHAR (MAX) के बीच तुलना करने के लिए इसे बदल दिया ) और मुझे निर्दिष्ट संख्याओं का उपयोग करते समय गति का अंतर नहीं मिलता है, लेकिन MAX का उपयोग करते समय। आप अपने आप से परीक्षण कर सकते हैं। उममीद है कि इससे मदद मिलेगी।

SET NOCOUNT ON;

--===== Test Variable Assignment 1,000,000 times using NVARCHAR(10)
DECLARE @SomeString NVARCHAR(10),
        @StartTime DATETIME;
--=====         
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='10', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(4000)
DECLARE @SomeString NVARCHAR(4000),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='4000', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO
--===== Test Variable Assignment 1,000,000 times using NVARCHAR(MAX)
DECLARE @SomeString NVARCHAR(MAX),
        @StartTime DATETIME;
 SELECT @startTime = GETDATE();
 SELECT TOP 1000000
        @SomeString = 'ABC'
   FROM master.sys.all_columns ac1,
        master.sys.all_columns ac2;
 SELECT testTime='MAX', Duration = DATEDIFF(ms,@StartTime,GETDATE());
GO

— Qmaster
स्रोत

4

यह तो दिलचस्प है। मेरे बॉक्स पर ऐसा लगता है कि MAX एक 4x धीमा है।

— स्टुकैम्पबेल

4

SQL सर्वर 2012 पर नए परिणाम: 10k 4k की तुलना में दो गुना धीमा है और MAX 4k की तुलना में 5.5 गुना धीमा है।

— कैसेंड्राड

1

समय का अधिकांश भाग वर्चर से नावरच (अधिकतम) तक निहित है। इसे आज़माएं: DECLARE \ @SomeString NVARCHAR (MAX), \ @abc NVARCHAR (अधिकतम) = N'ABC ', \ @StartTime DATETIME; चयन करें @startTime = GETDATE (); SELECT TOP 1000000 \ _SomeString = \ @abc from master.sys.all_columns ac1, master.sys.all_columns ac2; सेलेक्ट टेस्टटाइम = 'मैक्स', अवधि = डेटिडिफ (एमएस, \ @ स्टार्टटाइम, गेटडेट ()); इसे पोस्ट करने के लिए वैरिएबल से पहले इंसर्ट करना पड़ता था।

— क्वासि

4

एसएसडी पर एसक्यूएल सर्वर 2014: 150, 156, 716 (10, 4000, मैक्स)।

— मैक्सिम

2

इस चर्चा में कुछ वास्तविक संख्याओं को जोड़ने के लिए धन्यवाद। हम अक्सर भूल जाते हैं कि एक परीक्षण मामले का निर्माण अंतर्दृष्टि का सबसे तेज तरीका है।

— डेविड सी

13

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

— एलेक्स
स्रोत

8

अधिकतम या पाठ फ़ील्ड का उपयोग न करने का एक कारण यह है कि आप SQL सर्वर एंटरप्राइज संस्करण के साथ ऑनलाइन इंडेक्स रीबॉन्ड्स को भी ऑनलाइन नहीं कर सकते ।

— निक कवडिया
स्रोत

1

यह वही प्रतिबंध TEXT फ़ील्ड प्रकार के लिए है, इसलिए आपको अभी भी TEXT के बजाय VARCHAR (MAX) का उपयोग करना चाहिए।

— विल शावर

हम इसके कारण अपने क्लस्टर किए गए सूचकांक का पुनर्निर्माण नहीं कर सके। जब तक हम कॉलम को अपनी तालिका में निकाल नहीं सकते, तब तक हमें बहुत डिस्क स्थान खर्च करना होगा (हम 7 सेकंड से अधिक के लिए तालिका को लॉक नहीं कर सकते)

— चोको स्मिथ

4

समस्या सिर्फ मैंने पाया था कि हम SQL सर्वर 2005 पर हमारे अनुप्रयोगों का विकास, और एक उदाहरण में, हम एसक्यूएल सर्वर 2000 मैं सिर्फ सीखा है, के समर्थन के लिए मुश्किल तरीके से SQL Server 2000 varchar या के लिए MAX विकल्प की तरह नहीं है nvarchar।

— mattruma
स्रोत

2

तो क्यों न केवल सबसे कम आम भाजक पर विकसित किया जाए?

— बिंकी २ b

4

खराब विचार जब आप जानते हैं कि क्षेत्र एक निर्धारित सीमा में होगा- उदाहरण के लिए 5 से 10 वर्ण। मुझे लगता है कि मैं केवल अधिकतम का उपयोग करूंगा अगर मुझे यकीन नहीं था कि लंबाई क्या होगी। उदाहरण के लिए एक टेलीफोन नंबर वर्णों की एक निश्चित संख्या से अधिक कभी नहीं होगा।

क्या आप ईमानदारी से कह सकते हैं कि आप अपनी तालिका में प्रत्येक क्षेत्र के लिए अनुमानित लंबाई आवश्यकताओं के बारे में अनिश्चित हैं?

मुझे आपकी बात पर विश्वास है, हालांकि कुछ ऐसे क्षेत्र भी हैं, जिन पर मैं निश्चित रूप से वर्चर (अधिकतम) का उपयोग करने पर विचार करूंगा।

दिलचस्प बात यह है कि एमएसडीएन डॉक्स ने इसे अच्छी तरह से जोड़ दिया:

जब स्तंभ डेटा प्रविष्टियों का आकार काफी भिन्न होता है, तो varchar का उपयोग करें। स्तंभ डेटा प्रविष्टियों के आकार में काफी भिन्नता होने पर, varchar (अधिकतम) का उपयोग करें, और आकार 8,000 बाइट्स से अधिक हो सकता है।

नहीं है यहां मुद्दा यह है पर एक दिलचस्प चर्चा ।

— RichardOD
स्रोत

2

टेलीफोन नंबरों जैसी चीजों के लिए, मैं varchar के बजाय एक char फ़ील्ड का उपयोग करने के लिए अधिक सहमत होगा। जब तक आप अपने भंडारण में एक मानक बनाए रख रहे हैं और आपको विभिन्न देशों के फोन नंबरों के बारे में चिंता करने की आवश्यकता नहीं है, तब तक आपको किसी फोन नंबर की तरह एक चर क्षेत्र की आवश्यकता नहीं होनी चाहिए (10 बिना किसी स्वरूपण) या ज़िप कोड (5 या 9-10 यदि आप अंतिम चार अंक जोड़ते हैं), आदि

— TheTXI

मैं उन टेलीफोन नंबरों का जिक्र कर रहा था जो लंबाई में भिन्न हो सकते हैं। शायद मुझे जवाब में यह कहना चाहिए। कुछ भी जो निश्चित लंबाई है मैं एक चार क्षेत्र का उपयोग करेगा।

— रिचर्डॉड

या शायद मुझे अपनी टिप्पणी nchar या char में कहा जाना चाहिए। :-)

— रिचर्डॉड

2

एक टेलीफोन नंबर में पात्रों की संख्या बहुत अधिक व्यावसायिक आवश्यकता है। यदि आपको संख्या के साथ अंतर्राष्ट्रीय मानक कोड संग्रहीत करने की आवश्यकता होती है, तो यह 10. से अधिक हो सकता है या दुनिया के कुछ हिस्से में एक फ़ोन नंबर के लिए 10 से अधिक अंक हो सकते हैं। IPV4 के IPV6 संक्रमण के मामले की कल्पना करें। किसी ने यह तर्क नहीं दिया होगा कि अच्छे पुराने आईपीवी 4 दिनों में हमें 12 से अधिक अंकों की आवश्यकता थी। IPV6 प्रचलित हो जाए तो यह अच्छा नहीं हो सकता है। यह समय की अवधि में फिर से एक व्यावसायिक नियम है। जैसा कि कहा गया है, परिवर्तन एकमात्र स्थिर चीज है जिसकी हम अपेक्षा कर सकते हैं :)

— पेंसिलें

2

यह जानने के लिए सावधान रहें कि आप जानते हैं कि टेलीफ़ोन नंबर फ़ील्ड में कितने वर्ण हो सकते हैं, या वे किस प्रकार के वर्ण होंगे। जब तक सिस्टम उस डेटा का उपयोग वास्तव में डायल करने के लिए नहीं करता है (जिस स्थिति में आपको प्रारूपों के बारे में सख्त होना है), तो उपयोगकर्ता वैध रूप से अप्रत्याशित रूप से लंबे तार लगा सकता है जैसे "0123 456 78910 विस्तार 45 के लिए रिसेप्शन और फिर जेम्स को स्थानांतरित करें"।

— विंस बॉड्रेन

4

डेटाबेस का काम डेटा को स्टोर करना है ताकि इसका उपयोग उद्यम द्वारा किया जा सके। उस डेटा को उपयोगी बनाने का एक हिस्सा सुनिश्चित कर रहा है कि यह सार्थक हो। किसी को अपने पहले नाम के लिए असीमित संख्या में वर्ण दर्ज करने की अनुमति देना सार्थक डेटा सुनिश्चित नहीं करता है।

व्यापार की परत में इन बाधाओं का निर्माण एक अच्छा विचार है, लेकिन यह सुनिश्चित नहीं करता है कि डेटाबेस बरकरार रहेगा। यह गारंटी देने का एकमात्र तरीका है कि डेटा नियमों का उल्लंघन नहीं किया जाता है, उन्हें डेटाबेस में न्यूनतम स्तर पर लागू करना है।

— टॉम एच
स्रोत

6

IMO, डेटा लंबाई सीमाएँ विशुद्ध रूप से व्यावसायिक नियमों पर आधारित होती हैं, जो कि समय के साथ-साथ, अनुप्रयोग बढ़ने पर बदल सकती हैं। व्यावसायिक तर्क में व्यावसायिक नियमों को बदलना डीबी स्तर से आसान है। तो, मुझे लगता है कि db को पर्याप्त लचीला होना चाहिए और इसे व्यावसायिक नियमों से नहीं जोड़ा जाना चाहिए, जैसे कि पहले नाम की अधिकतम अनुमत लंबाई, जो कि आपके उपयोगकर्ता के दुनिया में मौजूद हिस्से पर बहुत निर्भर है।

— pencilslate

3

एक समस्या यह है कि यदि आप SQL सर्वर के कई संस्करणों के साथ काम कर रहे हैं, तो MAX हमेशा काम नहीं करेगा। इसलिए यदि आप विरासत डीबी या किसी अन्य स्थिति के साथ काम कर रहे हैं जिसमें कई संस्करण शामिल हैं, तो आप बेहतर रूप से सावधान रहना चाहिए।

— TheTXI
स्रोत

मुझे लगता है कि ओपी की ओर से अनिर्दिष्ट धारणा यह है कि वह पूरी तरह से 2005+ उदाहरणों के साथ काम कर रहा है, और यह कि उसके ऐप्स को 2000 (या, ack, low) संस्करणों पर काम करने की आवश्यकता नहीं होगी। मैं पूरी तरह से आपके साथ सहमत हूँ अगर पुराने संस्करणों का समर्थन करने की आवश्यकता है, हालांकि!

— जॉन रूडी

जॉन रूडी: मुझे लगता है कि यह मामला है, मुझे पता है कि मैं उन बाधाओं में खुद चला गया हूं जब मुझे नहीं लगता था कि मैं जा रहा हूं।

— TheTXI

दरअसल यह SQL CE 4 के कारण आधुनिक सामान के साथ अभी भी एक प्रचलित समस्या है जो MAX कॉलम प्रकारों का समर्थन नहीं करता है इसलिए इंटरऑपरेबिलिटी एक परेशानी है।

— जॉन सी सी

3

जैसा कि ऊपर बताया गया था, यह मुख्य रूप से भंडारण और प्रदर्शन के बीच एक व्यापार है। कम से कम ज्यादातर मामलों में।

हालांकि, कम से कम एक अन्य कारक है जिसे n / varchar (n) पर n / varchar (Max) चुनने पर विचार किया जाना चाहिए। क्या डेटा को अनुक्रमित किया जा रहा है (जैसे कि, एक अंतिम नाम)? चूंकि MAX परिभाषा को LOB माना जाता है, तो MAX के रूप में परिभाषित कुछ भी अनुक्रमण के लिए उपलब्ध नहीं है। और एक इंडेक्स के बिना, डेटा को शामिल करने वाले किसी भी लुक को WHERE क्लॉज में पहले से बता दिया जा सकता है, जिसे एक पूर्ण तालिका स्कैन में मजबूर किया जा सकता है, जो सबसे खराब प्रदर्शन है जिसे आप डेटा लुकअप के लिए प्राप्त कर सकते हैं।

— हैरी कूपर
स्रोत

2

1) SQL सर्वर को अधिक संसाधनों (आवंटित मेमोरी और सीपीयू समय) का उपयोग करना होगा, जब nvarchar (अधिकतम) बनाम nvarchar (n) से निपटने के लिए जहां n क्षेत्र के लिए एक विशिष्ट संख्या है।

2) प्रदर्शन के संबंध में इसका क्या मतलब है?

SQL सर्वर 2005 पर, मैंने 15 nvarchar (अधिकतम) कॉलम वाली तालिका से डेटा की 13,000 पंक्तियों को समझा। मैंने प्रश्नों को बार-बार समयबद्ध किया और फिर कॉलम को nvarchar (255) या उससे कम में बदल दिया।

ऑप्टिमाइज़ेशन से पहले के प्रश्नों का औसत 2.0858 सेकंड था। 1.90 सेकंड के औसत में परिवर्तन के बाद की क्वेरी। बुनियादी चयन * क्वेरी में सुधार के बारे में 184 मिलीसेकंड था। यह 8.8% का सुधार है।

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

— WWC
स्रोत

1

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

— कैड रूक्स
स्रोत

1

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

— टोनी
स्रोत

1

यदि एक पंक्ति में सभी डेटा (सभी स्तंभों के लिए) यथोचित रूप से 8000 या उससे कम वर्ण नहीं लेगा, तो डेटा स्तर पर डिज़ाइन को इसे लागू करना चाहिए।

डेटाबेस इंजन बहुत अधिक कुशल है जो सब कुछ ब्लॉब स्टोरेज से बाहर रखता है। छोटे आप एक पंक्ति बेहतर सीमित कर सकते हैं। अधिक पंक्तियों आप एक पृष्ठ में रटना कर सकते हैं बेहतर है। डेटाबेस केवल बेहतर प्रदर्शन करता है जब उसे कम पृष्ठों तक पहुंच प्राप्त करनी होती है।

— मैट स्प्रेडली
स्रोत

1

मेरे परीक्षणों से पता चला है कि चयन करते समय मतभेद हैं।

CREATE TABLE t4000 (a NVARCHAR(4000) NULL);

CREATE TABLE tmax (a NVARCHAR(MAX) NULL);

DECLARE @abc4 NVARCHAR(4000) = N'ABC';

INSERT INTO t4000
SELECT TOP 1000000 @abc4
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

DECLARE @abc NVARCHAR(MAX) = N'ABC';

INSERT INTO tmax
SELECT TOP 1000000 @abc
    FROM
    master.sys.all_columns ac1,
    master.sys.all_columns ac2;

SET STATISTICS TIME ON;
SET STATISTICS IO ON;

SELECT * FROM dbo.t4000;
SELECT * FROM dbo.tmax;

— Kvasi
स्रोत

0

दिलचस्प लिंक: जब आप पाठ का उपयोग कर सकते हैं तो VARCHAR का उपयोग क्यों करें?

यह PostgreSQL और MySQL के बारे में है, इसलिए प्रदर्शन विश्लेषण अलग है, लेकिन "खोजकर्ता" के लिए तर्क अभी भी रखता है: क्यों अपने आप को हमेशा उस चीज के बारे में चिंता करने के लिए मजबूर करें जो उस समय के एक छोटे प्रतिशत के लिए प्रासंगिक है? यदि आपने किसी ईमेल पते को एक चर में सहेजा है, तो आप 'स्ट्रिंग' का उपयोग करेंगे, न कि 'स्ट्रिंग को 80 वर्णों तक सीमित'।

— orip
स्रोत

1

यह तर्क देने के लिए कि आपको यह सुनिश्चित करने के लिए बाधाओं की जांच नहीं करनी चाहिए कि किसी व्यक्ति की आयु नकारात्मक संख्या नहीं है।

— जोनाथन एलन

मुझे डेटा शुद्धता और प्रदर्शन अनुकूलन के बीच अंतर दिखाई देता है।

— orip

0

मुख्य नुकसान मैं देख सकता हूं कि मान लें कि आपके पास यह है:

UI के लिए आवश्यक डेटा के बारे में आपको कौन सी जानकारी सबसे अधिक मिलती है?

इस

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](MAX) NULL,
                [CompanyName] [nvarchar](MAX) NOT NULL,
                [FirstName] [nvarchar](MAX) NOT NULL,
                [LastName] [nvarchar](MAX) NOT NULL,
                [ADDRESS] [nvarchar](MAX) NOT NULL,
                [CITY] [nvarchar](MAX) NOT NULL,
                [County] [nvarchar](MAX) NOT NULL,
                [STATE] [nvarchar](MAX) NOT NULL,
                [ZIP] [nvarchar](MAX) NOT NULL,
                [PHONE] [nvarchar](MAX) NOT NULL,
                [COUNTRY] [nvarchar](MAX) NOT NULL,
                [NPA] [nvarchar](MAX) NULL,
                [NXX] [nvarchar](MAX) NULL,
                [XXXX] [nvarchar](MAX) NULL,
                [CurrentRecord] [nvarchar](MAX) NULL,
                [TotalCount] [nvarchar](MAX) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

या यह?

            CREATE TABLE [dbo].[BusData](
                [ID] [int] IDENTITY(1,1) NOT NULL,
                [RecordId] [nvarchar](50) NULL,
                [CompanyName] [nvarchar](50) NOT NULL,
                [FirstName] [nvarchar](50) NOT NULL,
                [LastName] [nvarchar](50) NOT NULL,
                [ADDRESS] [nvarchar](50) NOT NULL,
                [CITY] [nvarchar](50) NOT NULL,
                [County] [nvarchar](50) NOT NULL,
                [STATE] [nvarchar](2) NOT NULL,
                [ZIP] [nvarchar](16) NOT NULL,
                [PHONE] [nvarchar](18) NOT NULL,
                [COUNTRY] [nvarchar](50) NOT NULL,
                [NPA] [nvarchar](3) NULL,
                [NXX] [nvarchar](3) NULL,
                [XXXX] [nvarchar](4) NULL,
                [CurrentRecord] [nvarchar](50) NULL,
                [TotalCount] [nvarchar](50) NULL,
                [Status] [int] NOT NULL,
                [ChangeDate] [datetime] NOT NULL
            ) ON [PRIMARY]

— carlos मार्टिनी
स्रोत

3

मैं व्यवसाय तर्क को यह बताना पसंद करूंगा कि कंपनी का नाम उस जानकारी के लिए डेटाबेस तालिका पर निर्भर होने के बजाय अधिकतम 50 वर्ण हो सकता है।

— खान

मैं जेफ से सहमत हूं। मुझे नहीं लगता कि आपके व्यापार नियमों को परिभाषित करने के लिए दृढ़ता की दुकान सही जगह है। और एक स्तरित वास्तुकला में आपके UI को दृढ़ता परत के बारे में भी नहीं पता होगा।

— स्टीकैम्पबेल

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

— बेन

2

टेबल डिफ के साथ क्या करना है? आपके पास अभी भी व्यावसायिक तर्क हो सकते हैं। मुझे लगता है कि आपकी बात से कोई मतलब नहीं है कि टेबल को कैसे डिज़ाइन किया गया है। यदि आप अभी भी अपने व्यवसाय की परत में किसी प्रकार की परिभाषा तैयार करना चाहते हैं, तो ऐसा ही हो। हालाँकि जो कुछ अधिक समझ में आता है, वह व्यवसायिक परत में वैसे भी एक संग्रहित खरीद का उपयोग कर रहा है; टेबल डिफ नहीं ??

— कार्लो मार्टिनी

1

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

— टिम एबेल

0

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

जो मुझे सी में डेटा संरचना संरेखण के बारे में सोचता है, और संरेखण के बारे में पता होना आम तौर पर एक गुड थिंग (टीएम) माना जाता है। समान विचार, अलग संदर्भ।

MSDN पृष्ठ और एक्सटेंशन के लिए पृष्ठ

रो-ओवरफ्लो डेटा के लिए MSDN पृष्ठ

— tsundoku
स्रोत

0

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

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

जाहिर है, हालांकि, यह सिर्फ आदर्श है, यदि आप एक मौजूदा प्रणाली के साथ काम कर रहे हैं तो संभावना यह है कि आपको इसे कम से कम अल्पावधि में अलग तरीके से करने की आवश्यकता होगी।

— स्टीफन व्हिप
स्रोत

-1

यह एक प्रदर्शन समस्या का कारण बनेगा, हालांकि यह कभी भी वास्तविक मुद्दों का कारण नहीं बन सकता है यदि आपका डेटाबेस छोटा है। प्रत्येक रिकॉर्ड हार्ड ड्राइव पर अधिक स्थान लेगा और डेटाबेस को डिस्क के अधिक क्षेत्रों को पढ़ने की आवश्यकता होगी यदि आप एक बार में बहुत सारे रिकॉर्ड खोज रहे हैं। उदाहरण के लिए, एक छोटा सा रिकॉर्ड एक सेक्टर में 50 फिट और एक बड़ा रिकॉर्ड फिट हो सकता है। आपको बड़े रिकॉर्ड का उपयोग करके डिस्क से 10 गुना अधिक डेटा पढ़ने की आवश्यकता होगी।

— डैन गोल्डस्टीन
स्रोत

5

-1। एक nvarchar(max)स्तंभ में संग्रहीत लंबाई 100 की एक स्ट्रिंग से अधिक डिस्क स्थान नहीं लेता है यदि यह एक nvarchar(100)स्तंभ में था।

— मार्टिन स्मिथ

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

-2

यह स्क्रीन डिज़ाइन को कठिन बना देगा क्योंकि आप अब यह अनुमान नहीं लगा पाएंगे कि आपके नियंत्रण कितने व्यापक होने चाहिए।

— pappes
स्रोत