用於SQL Server中電子郵件地址的NVARCHAR（？）

對於電子郵件地址，我應該爲SQL Server中的列提供多少空間。用於SQL Server中電子郵件地址的NVARCHAR（？）

我發現維基百科這樣的定義：

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個字符。

有什麼想法？

來源

2012-02-15 tugberk

我一直使用320基於你的後期計算。除非有人濫用它和垃圾，否則它不會讓你花費更多的錢。它可能花費你允許更少，因爲如果他們有合法的更長的電子郵件地址，你將有一個令人沮喪的用戶，現在你將不得不返回並更新架構，代碼，參數等。在我使用的系統（電子郵件服務提供商）合作時，我遇到的最長的電子郵件地址自然是大約120個字符 - 很明顯，他們只是爲了一個很長的電子郵件地址。

* 不是嚴格正確的，因爲內存授予估計是基於這樣的假設不同寬度的列的一半填充，因此更寬的列存儲相同數據可具有導致某些查詢的完全不同的性能特性。

而且我辯論NVARCHAR是否是必要的E-mail地址。我還沒有遇到過帶有Unicode字符的電子郵件地址 - 我知道這個標準支持它們，但是很多現有的系統都不支持它，如果那是你的電子郵件地址，那將是相當令人沮喪的。

儘管確實NVARCHAR的成本是空間的兩倍，但對於SQL Server 2008 R2，您可以從Unicode壓縮中受益，Unicode壓縮基本上將NVARCHAR列中的所有非Unicode字符視爲ASCII，因此可以將這些額外的字節返回。當然，壓縮僅適用於Enterprise + ...

減少空間要求的另一種方法是對所有觀察到的域名使用中央查找表，並將LocalPart和DomainID與用戶一起存儲，並僅存儲每個唯一的域名一旦。是的，這使得編程更加繁瑣，但是如果您擁有80,000個hotmail.com地址，則成本爲80,0000 x 4字節，而不是80,000 x 11個字節（壓縮或更少）。如果存儲或I/O是你的瓶頸，而不是CPU，這絕對是一個值得研究的選擇。

我寫的這個位置：

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

來源

2012-02-15 14:53:19

@tugberk對不起，在通知延遲，但我寫了關於這裏：http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/ – 2013-02-28 16:52:15

只爲info：ASP.NET成員資格提供程序爲Email字段使用「nvarchar（256）」創建數據庫「AspNetUsers」。 – Yanga 2017-09-30 05:01:57

@Yanga呃，謝謝你。 – 2017-09-30 09:34:59

我猜VARCHAR（320）將是基於ASCII的域名和電子郵件地址的正常範圍。但是我們不會開始看到unicode域名很快出現嗎？

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

也許NVARCHAR（320）是我們應該開始使用？

來源

2012-02-15 14:58:17

我真的相信，在我們開始在域名和電子郵件地址中廣泛採用Unicode字符之前，這將是一段很長的時間。只有電子郵件服務器的數量纔會對它們造成巨大的衝擊...... – 2012-02-15 15:00:48

你說得對。如果我們關心這個長度，我們應該爲unicode做同樣的事情。 – tugberk 2012-02-15 15:01:56

用於SQL Server中電子郵件地址的NVARCHAR（？）

回答

相關問題