ฉันเข้าใจว่าที่อยู่อีเมล 254 ตัวอักษรนั้นถูกต้อง แต่การใช้งานที่ฉันได้วิจัยมักจะใช้ varchar (60) ถึง varchar (80) หรือเทียบเท่า ตัวอย่างเช่น: คำแนะนำ SQL Serverนี้ใช้ varchar (80) หรือตัวอย่างของ Oracle

มีเหตุผลที่จะไม่ใช้จำนวนอักขระสูงสุด 254 ตัวหรือไม่ varchar ตามคำจำกัดความไม่ใช้ที่เก็บข้อมูลเท่าที่จำเป็นเพื่อเก็บข้อมูลหรือไม่

มีนัยยะเกี่ยวกับประสิทธิภาพ / การแลกเปลี่ยนที่สำคัญซึ่งทำให้การใช้งานจำนวนมากใช้น้อยกว่า 254 อักขระที่เป็นไปได้ทั้งหมดหรือไม่

VARCHAR(320)ผมเคยใช้เสมอ นี่คือเหตุผล มาตรฐานกำหนดข้อ จำกัด ต่อไปนี้:

• 64 ตัวอักษรสำหรับ "local part" (ชื่อผู้ใช้)
• 1 ตัวอักษรสำหรับ@สัญลักษณ์
• 255 ตัวอักษรสำหรับชื่อโดเมน

ตอนนี้บางคนจะบอกว่าคุณต้องการการสนับสนุนมากกว่านั้น บางคนจะบอกว่าคุณต้องรองรับ Unicode สำหรับชื่อโดเมน (หมายถึงคุณต้องเปลี่ยนไปใช้NVARCHAR) ในขณะที่มาตรฐานอาจมีการเปลี่ยนแปลงในระหว่างนี้ (เป็นเวลานานแล้วตั้งแต่ที่ฉันมีสกินในเกม) ฉันค่อนข้างมั่นใจว่าในเวลานี้เซิร์ฟเวอร์ส่วนใหญ่ในโลกจะไม่ยอมรับที่อยู่อีเมล Unicode และฉันมั่นใจ เซิร์ฟเวอร์จำนวนมากจะมีปัญหาในการสร้างและ / หรือการรับที่อยู่ด้วย> 320 ตัวอักษร

ที่กล่าวว่าคุณสามารถเตรียมการที่เลวร้ายที่สุดในตอนนี้ถ้าคุณชอบ (และถ้าคุณกำลังใช้การบีบอัดข้อมูลใน SQL Server 2008 R2 หรือดีกว่าคุณจะได้รับประโยชน์จากการบีบอัด Unicode ซึ่งหมายความว่าคุณจ่าย 2 ไบต์เท่านั้นสำหรับอักขระที่ต้องการจริงๆ มัน). วิธีนี้คุณสามารถสร้างคอลัมน์ของคุณให้กว้างที่สุดเท่าที่คุณต้องการและคุณสามารถปล่อยให้คนอื่น ๆ ขยะในที่นั่นนานเกินไปที่พวกเขาต้องการ - พวกเขาจะไม่ได้รับอีเมลหากพวกเขาให้ขยะเหมือนกับที่พวกเขาจะไม่ รับอีเมลหากส่วนแทรกล้มเหลว ปัญหาคือถ้าคุณปล่อยขยะที่ไม่ถูกต้องคุณต้องจัดการกับมัน และไม่ว่าคุณจะมีขนาดเท่าไหร่ - ถ้ามีคนลองใส่ 400 ตัวในคอลัมน์ 320 ตัวใคร ๆ ก็จะลองใส่ 1025 ตัวอักษรในคอลัมน์ 1024 ตัว ไม่มีเหตุผลที่บุคคลที่เหมาะสมควรมีที่อยู่อีเมล> 320 ตัวอักษรเว้นแต่จะใช้เพื่อทดสอบขอบเขตของระบบอย่างชัดเจน

แต่หยุดถามความคิดเห็นเกี่ยวกับเรื่องนี้ - และหยุดดูการใช้งานอื่น ๆ เพื่อขอคำแนะนำ (มันเกิดขึ้นในกรณีนี้ว่าสิ่งที่คุณอ้างอิงไม่ได้สนใจที่จะทำการบ้านของตัวเองและเพิ่งหยิบตัวเลขออกมาจากพวกเขาดีคุณรู้) . คุณสามารถเข้าถึงมาตรฐานได้โดยตรง - ตรวจสอบให้แน่ใจว่าคุณใช้เวอร์ชันล่าสุดสนับสนุนอย่างน้อยที่สุดและอยู่ด้านบนของมาตรฐานเพื่อให้คุณสามารถปรับตัวเข้ากับการเปลี่ยนแปลงในรายละเอียดได้

แก้ไขขอบคุณ @ypercube สำหรับ ping ในการแชท

นอกจากนี้คุณอาจไม่ต้องการทิ้งที่อยู่ทั้งหมดไว้ในคอลัมน์เดียวตั้งแต่แรก การทำให้เป็นมาตรฐานอาจแนะนำว่าคุณไม่ต้องการเก็บ@hotmail.com15 ล้านครั้งเมื่อ int FK ที่น่ากินมากขึ้นจะทำงานได้ดีและไม่มีค่าใช้จ่ายเพิ่มเติมของคอลัมน์ความยาวผันแปร คุณอาจจะยังปกติชื่อผู้ใช้ที่เป็น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 อักขระที่ถูกต้องรวมกับ localpart 1 ตัวที่ถูกต้อง สิ่งนี้ควรได้รับการยอมรับจากเซิร์ฟเวอร์ส่วนใหญ่ทั่วโลก แต่ดูเหมือนจะละเมิดขีดจำกัดความยาว 254 อักขระ ดังนั้นคุณจึงสร้างDomainsตารางที่มีข้อ จำกัด ด้านล่างของที่อยู่อีเมลที่ไม่ถูกต้องเมื่อโดเมนสามารถนำกลับมาใช้ใหม่เป็น URL 255 อักขระที่ถูกต้องได้หรือไม่

มีข้อควรพิจารณาบางประการเกี่ยวกับการตัดสินใจนี้ ก่อนอื่นคือการใช้การคาดการณ์ในปัจจุบันและอนาคตของข้อ จำกัด ที่จำเป็นที่ข้อมูลจะต้องสอดคล้องกับ มีเหตุผลที่คุณไม่ต้องการตั้งค่าทุกประเภทข้อมูลคอลัมน์สตริงเป็นvarchar(1024)เมื่อคุณเพิ่งเก็บสตริงที่ไม่ควรเกิน 32 ตัวอักษร (เน้นที่คำหลักควร )

หากคุณมีช่องโหว่บางประเภทที่อีเมลทั้งหมดได้รับการปรับเปลี่ยนให้มีอักขระ 255 ตัวคุณอาจมีผลกระทบต่อประสิทธิภาพการทำงานของการแบ่งหน้ากระดาษได้นาน นี้อาจดูเหมือนออกจากสามัญและส่วนใหญ่มีแนวโน้มเป็น แต่คุณจำเป็นต้องขนาดของข้อมูลของคุณความต้องการของธุรกิจ เช่นเดียวกับข้อ จำกัด อายุที่ฐานข้อมูลกับการอภิปรายแอปพลิเคชันฉันเชื่อมั่นว่าข้อ จำกัด ประเภทข้อมูลและค่าที่อนุญาตควรถูกบังคับใช้ในระดับข้อมูล

ซึ่งนำฉันไปยังจุดต่อไปของฉัน ฐานข้อมูลส่วนใหญ่เป็นเพียงชั้นข้อมูล แอปพลิเคชันระดับใช้อะไรบ้าง ตัวอย่างเช่นหากคุณมีแอปพลิเคชันที่คุณสามารถป้อนที่อยู่อีเมลได้เพียง 80 ตัวอักษรเหตุใดคุณจึงต้องการให้ประเภทข้อมูลมีขนาดใหญ่ขึ้น ธุรกิจจำเป็นต้องตอบคำถามสองข้อ:

1. สิ่งที่สามารถจะเป็น?
2. สิ่งที่ควรจะเป็น?

เท่านั้นคุณจะได้คำตอบของคุณ

varchar ตามคำจำกัดความไม่ใช้ที่เก็บข้อมูลเท่าที่จำเป็นเพื่อเก็บข้อมูลหรือไม่

ใช่และไม่. จะมีการเรียงลำดับของการชดเชยสำหรับข้อมูลความยาวแปรผันเพื่อบันทึกความยาวของมัน

RFC 5321 (ข้อมูลจำเพาะ SMTP ปัจจุบันล้าสมัย RFC2821) ระบุว่า:

ความยาวรวมสูงสุดของชื่อผู้ใช้หรือส่วนอื่น ๆ ในท้องถิ่นคือ 64 octets ความยาวรวมสูงสุดของชื่อโดเมนหรือหมายเลขคือ 255 octets

ดังนั้นเครื่องหมาย 64 + 255 + @ หมายถึง VARCHAR (320) คุณอาจจะไม่ต้องการสิ่งนี้มาก แต่ก็ปลอดภัยที่จะมีในกรณี

รูปแบบใด ๆ ของ VARCHAR จะใช้พื้นที่ในบล็อกข้อมูลเท่าที่จำเป็นเท่านั้น ไบต์เพิ่มเติมสำหรับการจัดเก็บความยาวนั้นเล็กน้อยเมื่อเทียบกับพื้นที่ที่จะสูญเสียโดยใช้ CHAR ที่มีความยาวคงที่แทน

เนื่องจากความยาวคอลัมน์ VARCHAR เป็น "ความยาวสูงสุด" จึงควรตั้งค่าให้มีขนาดใหญ่กว่าความยาวสูงสุดเท่าที่จะเป็นไปได้ไม่ว่าในกรณีใด ๆ จะใช้พื้นที่มากเท่าที่แต่ละแถวต้องการ แอปพลิเคชันโปรแกรมควรได้รับการออกแบบด้วยการเลื่อนฟิลด์หรืออะไรก็ตามที่เหมาะสมตามค่าปกติ

การออกแบบฐานข้อมูลเป็นเหมือนแผ่นกระดาษจริง ๆ โดยมีข้อ จำกัด เรื่องขนาด ไม่สามารถขยายหน้ากระดาษได้ ในการเปรียบเทียบนี้แอ็พพลิเคชันโปรแกรมเป็นเหมือนแบบฟอร์มที่พิมพ์บนหน้า มีจำนวนมากที่สามารถทำได้เพื่อปรับจำนวนข้อมูลที่เราสามารถเก็บไว้ในแบบฟอร์ม

แม้ว่าคำสั่งเพื่อเพิ่มขนาด VARCHAR อาจดูเรียบง่ายและรันได้ทันทีบนโต๊ะขนาดเล็กการทำเช่นนั้นบนตารางที่มีหลายพันแถวหรือมากกว่านั้นอาจจะต้องใช้ฐานข้อมูลบางประเภทในขณะที่สร้างข้อมูลและบล็อกดัชนีใหม่ วิธีหนึ่งคือการคัดลอกทุกอย่างไปยังตารางใหม่ที่มีคอลัมน์ขนาดใหญ่กว่า ไม่ว่าจะใช้เทคนิคอะไรมันก็ใหญ่โตขนดก ดังนั้นคุณควรพิจารณาขนาดคอลัมน์ VARCHAR ส่วนใหญ่ไม่เปลี่ยนรูปเมื่อโหลดตารางการผลิต

เป็นความเห็นต่อคำตอบที่ยอดเยี่ยมแล้ว

ก่อนอื่นถ้าคุณสร้างเขตข้อมูลเป็นvarchar(240)และคุณต้องการเปลี่ยนเป็นเขตข้อมูลที่ยาวกว่าในภายหลังให้กล่าวว่าvarchar(320)การเปลี่ยนแปลงนี้เป็นการดำเนินการเล็กน้อยบนเซิร์ฟเวอร์ฐานข้อมูล - แน่นอนขึ้นอยู่กับผลิตภัณฑ์ฐานข้อมูลของคุณ

alter table Schema.Object alter column EmailAddress varchar(320) ;

ประการที่สองขึ้นอยู่กับขนาดแถวเฉลี่ยและขนาดหน้าการใช้varchar(320)แทนvarchar(240)อาจไม่เปลี่ยนจำนวนหน้าที่จัดสรร (พื้นที่ดิสก์ที่ใช้จริงโดยตาราง)

ประการที่สามมีคนพูดคุยเกี่ยวกับการยืนยันที่อยู่อีเมล ฉันขอยืนยันว่ามีเพียงวิธีเดียวเท่านั้นในการตรวจสอบความถูกต้องของที่อยู่อีเมลและนั่นคือการส่งอีเมลไปให้ :-)

VARCHAR เป็นประเภทข้อมูลที่ดีที่สุดที่จะใช้สำหรับที่อยู่อีเมลเนื่องจากอีเมลมีความยาวแตกต่างกันไปมาก NVARCHAR เป็นอีกทางเลือกหนึ่ง แต่ฉันขอแนะนำให้ใช้เฉพาะในกรณีที่ที่อยู่อีเมลมีตัวอักษรเพิ่มเติมและจำไว้ว่าต้องใช้พื้นที่เก็บข้อมูลสองเท่าเมื่อเทียบกับ VARCHAR

ในสภาพแวดล้อมของฉันเราใช้ varchar (70) เพราะตัวที่ยาวที่สุดที่ฉันเจอมีความยาว 60-70 ตัว แต่มันก็ขึ้นอยู่กับฐานลูกค้าของ บริษัท คุณเช่นกัน นอกจากนี้โปรดทราบว่าคุณมีการตรวจสอบความถูกต้องทางอีเมลบางอย่างเพื่อความถูกต้องของที่อยู่อีเมล .. เช่นการใช้ข้อ จำกัด การตรวจสอบหรือ CHARINDEX

ใช้ SQL DOMAIN

หากคุณใช้เซิร์ฟเวอร์ฐานข้อมูลองค์กรควรมีวิธีเก็บที่อยู่อีเมลเช่นเดียวDOMAINกับที่มีระดับความถูกต้อง โดเมนถูกระบุในข้อมูลจำเพาะ SQL

โดเมนเป็นวัตถุที่ผู้ใช้กำหนดชื่อที่สามารถระบุเป็นทางเลือกให้กับชนิดข้อมูลในบางสถานที่ที่สามารถระบุชนิดข้อมูลได้ โดเมนประกอบด้วยประเภทข้อมูลอาจเป็นตัวเลือกเริ่มต้นและข้อ จำกัด เป็นศูนย์หรือมากกว่า (โดเมน)

ตัวอย่างเช่น PostgreSQL โอเพนซอร์สและฟรีสนับสนุนสิ่งนี้ยกเว้นข้อ จำกัด ใด ๆ ในการใช้งานข้อมูลจำเพาะคอลัมน์นั้นมีอีเมลที่ถูกต้อง ตัวอย่างเช่นคุณสามารถ ..

• สร้างที่กำหนดเองDOMAINผ่านข้อกำหนด HTML5 ของอีเมล
• หรือมากกว่าข้อมูลจำเพาะทางอีเมล RFC822, RFC2822, RFC5322
• สร้างแบบกำหนดเองDOMAINที่ตรวจสอบเซิร์ฟเวอร์สำหรับเรคคอร์ด MX ขณะทำการตรวจสอบ

ฉันประเมินตัวเลือกเหล่านี้ในคำตอบนี้เฉพาะกับ PostgreSQL