SQL सर्वर

Question

में ईमेल पते के लिए NVARCHAR (?) ईमेल पते के लिए, SQL सर्वर में कॉलम को मुझे कितनी जगह देना चाहिए।

मैं विकिपीडिया पर इस परिभाषा पाया:

http://en.wikipedia.org/wiki/Email_address

ईमेल पतों की प्रारूप स्थानीय-भाग @ डोमेन और डोमेन नाम जहां स्थानीय-भाग 64 वर्णों का हो सकता है में अधिकतम 253 वर्ण हैं - लेकिन अधिकतम 256 वर्ण अग्रेषित या रिवर्स पथ की लंबाई पूरे ईमेल पते को 254 वर्णों से अधिक नहीं होने पर

और यह एक:

http://askville.amazon.com/maximum-length-allowed-email-address/AnswerViewer.do?requestId=1166932

अब के लिए

तो, ई-मेल पते के लिए अनुमति की कुल पात्रों 64 (स्थानीय हिस्सा) + 1 ("@" चिह्न) + 255 (डोमेन है भाग) = 320

यह संभव है कि भविष्य में वे स्थानीय भाग सीमा 128 वर्णों में वृद्धि करेंगे। जो कुल 384 वर्ण बना देगा।

कोई विचार?

Answer 1

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

* नहीं पूर्णतया सत्य है, क्योंकि स्मृति अनुदान अनुमान इस धारणा है कि अलग-चौड़ाई कॉलम आधा आबादी पर आधारित होते हैं, इसलिए एक व्यापक एक ही डेटा भंडारण स्तंभ नेतृत्व कर सकते हैं करने के लिए कुछ प्रश्नों के एकदम अलग प्रदर्शन विशेषताओं ।

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

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

एक और तरीका स्थान आवश्यकताओं को कम करने के सभी मनाया डोमेन नाम के लिए एक केंद्रीय लुकअप तालिका का उपयोग करने के लिए, और उपयोगकर्ता के साथ LocalPart और DomainID की दुकान है, और केवल प्रत्येक अद्वितीय डोमेन नाम की दुकान है एक बार। हां यह अधिक बोझिल प्रोग्रामिंग के लिए बनाता है, लेकिन यदि आपके पास 80,000 हॉटमेल.com पते हैं, तो लागत 80,000 x 11 बाइट्स (या संपीड़न के साथ कम) के बजाय 80,0000 x 4 बाइट्स है।यदि स्टोरेज या आई/ओ आपकी बाधा है, और सीपीयू नहीं है, तो यह निश्चित रूप से जांच के लायक विकल्प है।

मैं यहाँ इस बारे में लिखा है:

http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/

Answer 2

मुझे लगता है कि VARCHAR (320) एक ASCII आधारित डोमेन नाम और ईमेल पते के लिए सामान्य सीमा होगी। लेकिन क्या हम जल्द ही कुछ यूनिकोड डोमेन नाम दिखाना शुरू नहीं करेंगे?

http://en.wikipedia.org/wiki/Internationalized_domain_name

शायद NVARCHAR (320) क्या हम प्रयोग कर शुरू कर देना चाहिए है?