আমি সবসময় ব্যবহার করেছি VARCHAR(320)। কারণটা এখানে. মানটি নিম্নলিখিত সীমাবদ্ধতাগুলি নির্দেশ করে:
- "স্থানীয় অংশ" (ব্যবহারকারীর নাম) এর জন্য 64 টি অক্ষর।
@প্রতীকটির জন্য 1 টি অক্ষর ।- ডোমেন নামের 255 টি অক্ষর।
এখন, কিছু লোকেরা বলবে যে এর চেয়ে আরও বেশি আপনাকে সমর্থন করা দরকার। কিছু লোকেরা এও বলবে যে আপনাকে ডোমেন নামগুলির জন্য ইউনিকোড সমর্থন করতে হবে (যার অর্থ আপনাকে স্যুইচ করতে হবে NVARCHAR)। যদিও এর মধ্যে স্ট্যান্ডার্ডটি পরিবর্তিত হতে পারে (যদিও গেমটিতে আমার ত্বক রয়েছে সেহেতু এটি বেশ কিছুক্ষণ হয়ে গেছে) তবে আমি যথেষ্ট আত্মবিশ্বাসী যে বিশ্বের বেশিরভাগ সার্ভারগুলি ইউনিকোড ই-মেইল ঠিকানাগুলি গ্রহণ করবে না এবং আমি নিশ্চিত অনেক সার্ভারের>> 320 টি অক্ষর যুক্ত ঠিকানা তৈরি এবং / বা স্বীকার করার সমস্যা থাকবে।
এটি বলেছিল, আপনি এখন সবচেয়ে খারাপের জন্য প্রস্তুত করতে পারেন, যদি আপনি চান (এবং যদি আপনি এসকিউএল সার্ভার ২০০৮ আর 2 বা আরও ভাল ডেটা সংক্ষেপণ ব্যবহার করেন তবে আপনি ইউনিকোড সংকোচনের মাধ্যমে উপকৃত হবেন, যার অর্থ আপনি কেবলমাত্র অক্ষরের জন্য কেবলমাত্র 2 বাইট জরিমানা প্রদান করবেন) এটা)। এইভাবে আপনি নিজের কলামটি নিজের ইচ্ছাকে আরও প্রশস্ত করতে পারবেন এবং লোকেরা যাতে চান সেখানে যে কোনও দীর্ঘ-জঞ্জাল স্টাফ করতে দিতে পারেন - তারা আপনাকে যেমন কোনও জাঙ্ক দেয় ঠিক তেমন কোনও ই-মেইল পাবেন না sertোকানো ব্যর্থ হলে একটি ইমেল পান। সমস্যাটি হ'ল যদি আপনি অবৈধ জঞ্জাল প্রবেশ করতে দেন, আপনিএটি মোকাবেলা করতে হবে। এবং আপনি এটি আকারটি তৈরি করুন তা বিবেচনা করে না - কেউ যদি 320-অক্ষর কলামে 400 টি অক্ষর স্টাফ করার চেষ্টা করে তবে কেউ 1025 অক্ষরকে 1024-অক্ষর কলামে স্টাফ করার চেষ্টা করবে। কোনও বুদ্ধিমান ব্যক্তির কোনও ই-মেইল ঠিকানা> 320 টি অক্ষর থাকার কোনও কারণ নেই যদি না তারা এটিকে সিস্টেমের সীমানা স্পষ্টভাবে পরীক্ষা করতে ব্যবহার করে।
তবে এ সম্পর্কে মতামত জিজ্ঞাসা করা বন্ধ করুন - এবং দিকনির্দেশের জন্য অন্যান্য বাস্তবায়নগুলি অনুসন্ধান করা বন্ধ করুন (এক্ষেত্রে এমনটি ঘটে যা আপনি উল্লেখ করেছেন তারা তাদের নিজস্ব গৃহকর্ম সম্পাদন করতে বিরত করেন নি এবং কেবল তাদের থেকে সংখ্যাগুলি বেছে নিয়েছে, ভাল, আপনি জানেন) । আপনার স্ট্যান্ডার্ডটিতে সরাসরি অ্যাক্সেস রয়েছে - আপনি সর্বাধিক বর্তমান সংস্করণের সাথে পরামর্শ করেছেন কিনা তা নিশ্চিত করুন, ন্যূনতম হিসাবে সমর্থন করুন এবং মানের শীর্ষে থাকুন যাতে আপনি চশমা পরিবর্তনের সাথে মানিয়ে নিতে পারেন।
আড্ডায় পিংয়ের জন্য @ সাইপারকিউকে ধন্যবাদ সম্পাদনা করুন ।
একদিকে যেমন, সম্ভবত আপনি পুরো ঠিকানাটি প্রথম একক কলামে ডাম্প করতে চান না। সাধারণকরণ প্রস্তাব দিতে পারে যে আপনি @hotmail.comযখন 15 মিলিয়ন বার সঞ্চয় করতে চান না তখন যখন খুব বেশি স্কিনিয়ার এফ কে ইন্ট ঠিকঠাক কাজ করে এবং পরিবর্তনশীল দৈর্ঘ্যের কলামগুলির অতিরিক্ত ওভারহেড না থাকে। আপনি ব্যবহারকারীর নামটি সাধারণ হিসাবে ব্যবহার করতে পারেন 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-অক্ষর লোকালপার্টের সাথে একত্রিত হলে কী ঘটে তা নিয়ে sensক্যমত্য বলে মনে হয় না। এটি বিশ্বব্যাপী বেশিরভাগ সার্ভারদের দ্বারা গ্রহণ করা উচিত তবে এই 254-চরিত্রের সীমাটি লঙ্ঘন করে বলে মনে হচ্ছে। Domainsইমেল ঠিকানাগুলির জন্য দৈর্ঘ্যের উপর কৃত্রিমভাবে কম সীমাবদ্ধতা রয়েছে এমন কোনও টেবিলটি তৈরি করেন , যখন ডোমেনটি বৈধ 255-অক্ষরের URL হিসাবে পুনরায় ব্যবহার করা যেতে পারে?