SQL電子郵件字段應該多長時間？

Question

我認識到，一個電子郵件地址可以基本上無限長，所以我強加給我的varchar電子郵件地址字段的任何大小將是任意的。但是，我想知道「標準」是什麼？你們做了多久？ （對於名稱字段相同的問題...）

更新：顯然爲電子郵件地址的最大長度是320（< = 64名部分，< = 255結構域）。你用這個嗎？

Answer 1

理論上的限制真的很長，但您真的需要擔心這些長的電子郵件地址嗎？如果有人不能使用100個字符的電子郵件登錄，你真的關心嗎？我們實際上更喜歡他們不能。

一些統計數據可能會對這個問題有所瞭解。我們分析了超過1000萬個電子郵件地址的數據庫。這些地址未被確認，因此存在無效地址。這裏有一些有趣的事實，

1. 最長有效期一種是89
2. 有數百個較長的達到我們的列（255）的限制，但它們是通過目測顯然是假的。
3. 長度分佈的峯值爲19.
4. 沒有長尾巴。一切後，38

我們通過丟棄任何超過40長的好消息是，沒有人抱怨，但壞消息是不是多條記錄得到了清理清理DB大幅下降。

Answer 2

我過去剛做了255次，因爲這是短暫的但不是太短輸入的根深蒂固的標準。那，我是一個習慣的生物。

但是，由於最大值是319，所以我會在列上做nvarchar(320)。記得@！

nvarchar將不會使用您不需要的空間，所以如果您只有20個字符的電子郵件地址，它將只佔用20個字節。這與nchar相反，其將總是佔據其最大值（它用空格填充該值）。

因爲它是Unicode，所以我也使用nvarchar代替varchar。考慮到電子郵件地址的波動性，這絕對是一種方式。

Answer 3

如果你確實在做這件事，可以使用username varchar（60），domain varchar（255）。然後，您可以對域使用情況做出荒謬的統計數據，這比將數據作爲單個字段稍微快一點。如果你真的感覺到優化，那麼這也將使你的SMTP服務器能夠用更少的連接/更好的批量發送電子郵件。

Answer 4

對於電子郵件，不管規範如何，我幾乎總是用512（nvarchar）。名字和姓氏是相似的。

真的，你需要看看你有多少關心有一點額外的數據。對我來說，大多數情況下，這不是一個擔心，所以我會在保守方面犯錯。但是，如果您已經通過邏輯準確的方式決定需要節約空間，那就這樣做。但總的來說，保守的野外大小，生活應該是好的。

請注意，可能並非所有的電子郵件客戶端都支持RFC，因此不管它說什麼，您都可能在野外遇到不同的事情。

Answer 5

以下電子郵件地址是唯一的94個字符：

i.have.a.really.long.name.like.seetharam.krishnapillai@AReallyLongCompanyNameOfSomeKind.com.au

你會真正使用這樣的電子郵件地址？ 會有人嗎？當然不是。輸入時間太長，難以記憶。

如果數據庫中的磁盤空間有問題，並且您不介意百萬中的某個用戶必須使用輔助電子郵件地址來使用您的站點，請使用50個字符： 123456789.123456789.123456789@123456789。 （大多數情況下，磁盤空間不再是問題了，是不是？）

Answer 6

RFC 5321（當前SMTP屬，淘汰了RFC2821）規定：

4.5.3.1.1。本地部分

用戶名稱或其他本地部分的最大總長度爲64
八比特組。

4.5.3.1.2。 Domain

域名或號碼的最大總長度爲255個八位字節。

這隻適用於localpart @ domain，總共320個ASCII（7位）字符。

如果計劃一定要規範你的數據，也許分裂的localpart和域成單獨的領域，更多的事情要記住：

• 稱爲VERP的技術可能會導致全長localparts自動生成的郵件（可能與您的用例無關）
• 域不區分大小寫;建議降低域名部分
• localparts區分大小寫; user@domain.com和USER@domain.com是技術上不同的地址，儘管domain.com 的策略可能是將這兩個地址視爲等效。最好將本地部分大小寫摺疊限制爲已知要執行此操作的域。

Answer 7

我使用VARCHAR（64）我不認爲任何人都可以有較長的電子郵件

Answer 8

根據這一文本的基礎上，適當的RFC文檔，它不是320而是254： http://www.eph.co.uk/resources/email-address-length-faq/