मैंने हमेशा उपयोग किया है VARCHAR(320)। यहाँ पर क्यों। मानक निम्नलिखित सीमाओं को निर्धारित करता है:
- "स्थानीय भाग" (उपयोगकर्ता नाम) के लिए 64 अक्षर।
@प्रतीक के लिए 1 वर्ण ।- डोमेन नाम के लिए 255 अक्षर।
अब, कुछ लोग कहेंगे कि आपको इससे अधिक समर्थन करने की आवश्यकता है। कुछ लोग यह भी कहेंगे कि आपको डोमेन नाम के लिए यूनिकोड का समर्थन करने की आवश्यकता है (जिसका अर्थ है कि आपको स्विच करना होगा NVARCHAR)। हालांकि इस बीच मानक बदल सकता है (खेल में त्वचा होने के बाद से कुछ समय हो गया है), मुझे पूरा विश्वास है कि इस समय दुनिया में अधिकांश सर्वर यूनिकोड ई-मेल पते स्वीकार नहीं करेंगे, और मुझे यकीन है कई सर्वरों में>> 320 अक्षरों के साथ पते बनाने और / या स्वीकार करने के मुद्दे होंगे।
उस ने कहा, अब आप सबसे खराब तैयारी कर सकते हैं, यदि आपको पसंद है (और यदि आप SQL Server 2008 R2 में डेटा संपीड़न का उपयोग कर रहे हैं या बेहतर है, तो आप यूनिकोड संपीड़न से लाभान्वित होंगे, जिसका अर्थ है कि आपको केवल पात्रों के लिए 2 बाइट जुर्माना देना होगा जो वास्तव में आवश्यक हैं यह)। इस तरह से आप अपने कॉलम को जितना चाहें उतना चौड़ा बना सकते हैं, और आप लोगों को किसी भी बहुत लंबे कबाड़ में सामान दे सकते हैं, जो वे चाहते हैं - यदि वे आपको कबाड़ नहीं देते हैं तो वे आपको एक ई-मेल प्राप्त नहीं करेंगे। यदि ई-मेल विफल रहता है तो ई-मेल प्राप्त करें। समस्या यह है कि यदि आप अवैध कबाड़ को अंदर आने देते हैं, तो आपइससे निपटना होगा। और इससे कोई फर्क नहीं पड़ता कि आप इसे किस आकार का बनाते हैं - यदि कोई 400 वर्णों को 320-वर्ण स्तंभ में रखने का प्रयास करेगा, तो कोई 1025 वर्णों को 1024-वर्ण स्तंभ में रखने का प्रयास करेगा। किसी भी समझदार व्यक्ति के पास ई-मेल पता> 320 वर्ण होने का कोई कारण नहीं है जब तक कि वे स्पष्ट रूप से सिस्टम सीमाओं का परीक्षण करने के लिए इसका उपयोग नहीं कर रहे हैं।
लेकिन इस पर राय मांगना बंद करें - और मार्गदर्शन के लिए अन्य कार्यान्वयनों को देखना बंद करें (यह सिर्फ इस मामले में ऐसा होता है कि जिन लोगों को आपने संदर्भित किया है वे अपने स्वयं के होमवर्क करने के लिए परेशान नहीं हुए और बस अपने से बाहर संख्याएं ले लीं, अच्छी तरह से, आप जानते हैं) । आपके पास मानक तक सीधी पहुंच है - सुनिश्चित करें कि आप सबसे वर्तमान संस्करण से परामर्श करते हैं, एक न्यूनतम के रूप में समर्थन करते हैं, और मानक के शीर्ष पर रहें ताकि आप ऐनक में परिवर्तन के लिए अनुकूल हो सकें।
चैट में पिंग के लिए @ypercube को EDIT धन्यवाद।
एक तरफ के रूप में, शायद आप पूरे पते को पहली बार में एक एकल कॉलम में डंप नहीं करना चाहते हैं। सामान्यीकरण यह सुझाव दे सकता है कि आप @hotmail.com15 मिलियन बार स्टोर नहीं करना चाहते हैं जब एक बहुत स्किनियर एफके इंट बस ठीक काम करेगा और चर लंबाई के कॉलम का अतिरिक्त ओवरहेड नहीं होगा। आप उपयोगकर्ता नाम को सामान्य भी कर सकते हैं, जैसा कि john.smith@hotmail.comऔर john.smith@gmail.comएक सामान्य उपयोगकर्ता नाम साझा करें - वे एक दूसरे को नहीं जानते हैं लेकिन आपका डेटाबेस इस बारे में परवाह नहीं करता है।
मैंने यहाँ इसके बारे में कुछ बात की:
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
http://www.mssqltips.com/sqlservertip/2671/storing-email-addresses-more-efficiently-in-sql-server--part-2/
यह ऊपर दी गई 254-वर्ण सीमा के लिए चुनौतियों का परिचय देता है, क्योंकि जब कोई मान्य 255-वर्ण डोमेन एक मान्य 1-वर्ण स्थानीयता के साथ संयुक्त होता है, तो इसके बारे में सर्वसम्मति प्रतीत नहीं होती है। इसे दुनिया भर के अधिकांश सर्वरों द्वारा स्वीकार किया जाना चाहिए लेकिन यह 254-वर्ण सीमा का उल्लंघन करता है। तो क्या आप एक Domainsतालिका बनाते हैं जिसमें ई-मेल पते के लिए लंबाई पर कृत्रिम रूप से कम प्रतिबंध है, जब डोमेन को एक वैध 255-वर्ण URL के रूप में फिर से उपयोग किया जा सकता है?