254文字の電子メールアドレスが有効であることは理解していますが、調査した実装では、varchar（60）からvarchar（80）または同等のものを使用する傾向があります。例：このSQL Serverの推奨事項では、varchar（80）またはこのOracleの例を使用しています
最大254文字の最大文字数を使用しない理由はありますか？定義上、varcharはデータを保持するために必要なだけのストレージを使用しませんか？
非常に多くの実装で使用可能な254文字よりも少ない文字を使用する、パフォーマンスへの重要な意味/トレードオフがありますか？
回答:
私はいつも使用していVARCHAR(320)ます。その理由は次のとおりです。標準では、次の制限が規定されています。
@シンボルに1文字。さて、それ以上をサポートする必要があると言う人もいるでしょう。ドメイン名にUnicodeをサポートする必要があると言う人もいます（つまり、に切り替える必要がありますNVARCHAR）。規格はその間に変更される可能性がありますが（ゲームにスキンを付けてからしばらく経ちました）、この時点で世界中のほとんどのサーバーがUnicode電子メールアドレスを受け入れないことを確信しています。多くのサーバーでは、320文字を超えるアドレスの作成や受け入れに問題が発生します。
とはいえ、必要に応じて最悪の事態に備えることができます（SQL Server 2008 R2以降でデータ圧縮を使用している場合は、Unicode圧縮のメリットがあります。つまり、実際に必要な文字に対して2バイトのペナルティのみを支払うということです。それ）。このようにして、列を好きなだけ広げることができ、長すぎるジャンクを好きなように詰めることができます-ジャンクを与えない場合は、電子メールを受信しません挿入が失敗した場合、電子メールを受信します。あなたは、中に無効なジャンクを許可すれば問題がありますそれに対処する必要があります。そして、あなたがそれをどんなサイズにしても、誰かが400文字を320文字の列に詰め込もうとすると、誰かが1025文字を1024文字の列に詰め込もうとします。賢明な人がシステム境界を明示的にテストするためにそれを使用している場合を除き、賢明な人が320文字を超える電子メールアドレスを持っている必要はありません。
しかし、これに関する意見を求めるのをやめてください-そして、ガイダンスのために他の実装を見るのをやめてください（あなたが参照したものが自分の宿題をすることを気にせず、彼らから数字を選んだだけです） 。標準に直接アクセスできます。最新バージョンを参照し、最低限サポートするようにしてください。また、仕様の変更に適応できるように、標準を維持してください。
EDITは感謝チャットでのpingのため@ypercubeします。
余談ですが、そもそもアドレス全体を1つの列にダンプしたくないでしょう。正規化により@hotmail.com、よりスキニーなFK intが正常に機能し、可変長列の追加オーバーヘッドがない場合、1500万回保存したくないことが示唆される場合があります。また、ユーザー名を正規化して、共通のユーザー名john.smith@hotmail.comをjohn.smith@gmail.com共有することもできます-彼らはお互いを知りませんが、データベースはそれを気にしません。
私はここでこれについていくつか話しました：
http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/
ただし、有効な255文字のドメインが有効な1文字のローカル部分と組み合わされたときに何が起こるかについてコンセンサスがないように見えるため、上記の254文字の制限に課題が生じます。これは世界中のほとんどのサーバーで受け入れられるべきですが、この254文字の制限に違反しているようです。Domainsドメインを有効な255文字のURLとして再利用できる場合、電子メールアドレスの長さの人為的により低い制限を持つテーブルを作成しますか？
この決定にはいくつかの考慮事項があります。何よりもまず、データが準拠しなければならない必要な制限の現在および将来の予測を使用することです。32文字を超えvarchar(1024)てはならない文字列（shouldキーワードの強調）のみを格納する場合に、すべての文字列列のデータ型を設定したくない理由があります。
メールがすべて255文字になるように変更される脆弱性がある場合、ページ分割のパフォーマンスへの影響が長くなる可能性があります。これは普通ではないように思えるかもしれませんが、ほとんどの場合そうですが、ビジネス要件に合わせてデータのサイズを調整する必要があります。データベースとアプリケーションの議論における古くからの制約のように、私はデータ型の制限と許容値もデータ層で強制されるべきだと固く信じています。
それは私の次のポイントに私を導きます。ほとんどの場合、データベースは単なるデータ層です。アプリケーション層は何を利用しますか？たとえば、メールアドレスに80文字しか入力できないアプリケーションがある場合、データタイプをもっと大きくしたいのはなぜですか？ビジネスは2つの質問に答える必要があります。
そうしてはじめて、答えが得られます。
定義上、varcharはデータを保持するために必要なだけのストレージを使用しませんか？
はいといいえ。可変長データの長さを記録するためのオフセットのようなものがあります。
VARCHARのバリエーションは、データブロック内で必要なだけのスペースを使用します。長さを格納するための追加のバイトは、代わりに固定長のCHARを使用して無駄になるスペースと比べると些細です。
VARCHAR列の長さは実際には「最大長」であるため、どのような状況でも可能な最大長よりも大きく設定する必要があります。各行に必要なだけのスペースが使用されます。アプリケーションプログラムは、スクロールフィールドまたは一般的な値に基づいて意味のあるもので設計する必要があります。
データベース設計は、サイズに関する厳しい制限を設定するという点で物理的な紙のようなものです。紙のページは拡大できません。この類推で、アプリケーションプログラムはページに印刷されたフォームのようなものです。フォームに保持できるデータの量を調整するためにできることはたくさんあります。
VARCHARサイズを大きくするコマンドは単純に見え、小さなテーブルで即座に実行できますが、数千行以上のテーブルでこれを行うには、おそらくすべてのデータおよびインデックスブロックを再生成するときに何らかのデータベース静止が必要になります。1つの方法は、すべてをより大きな列を持つ新しいテーブルにコピーすることです。どんなテクニックが使われようと、それは大きな毛深い取引です。したがって、実稼働テーブルがロードされると、VARCHAR列のサイズはほとんど不変であると考える必要があります。
すでに優れた答えへのコメントとしてここに：
最初に、フィールドをasとして作成し、varchar(240)後でそれをより長いフィールドにvarchar(320)変更する場合、この変更はデータベースサーバーでの簡単な操作である必要があります-もちろん、データベース製品によって異なります。
alter table Schema.Object alter column EmailAddress varchar(320) ;2番目に、平均行サイズとページサイズに応じて、varchar(320)代わりにを使用しvarchar(240)ても、割り当てられたページの数（テーブルが実際に占有するディスク領域）は変わらない場合があります。
第三に、上記の誰かがメールアドレスの検証について話しました。私は、電子メールアドレスを検証する確実な方法は1つしかなく、そのアドレスに電子メールを送信することだと主張します。:-)
電子メールは長さによって大きく異なるため、VARCHARは電子メールアドレスに使用するのに最適なデータ型です。NVARCHARも代替手段ですが、電子メールアドレスに拡張文字が含まれている場合にのみ使用することをお勧めします。VARCHARと比較して2倍のストレージスペースが必要であることに注意してください。
私の環境では、varchar（70）を使用します。これは、私が出会った中で最も長いものが60〜70文字の長さですが、それは会社の顧客ベースにも依存します。また、補足として、チェック制約やCHARINDEXを使用するなど、電子メールアドレスの有効性を確認するための電子メール検証チェックがあることを確認してください。
DOMAINエンタープライズデータベースサーバーを使用している場合DOMAIN、何らかの方法で有効性のあるメールアドレスを保存する必要があります。ドメインはSQL仕様で指定されています
ドメインは、データ型を指定できる特定の場所で、データ型の代替として指定できる名前付きのユーザー定義オブジェクトです。ドメインは、データ型、場合によってはデフォルトオプション、およびゼロ以上の（ドメイン）制約で構成されます。
たとえば、無料でオープンソースのPostgreSQLはこれをサポートします。仕様の実装に制限がない限り、列自体に有効な電子メールが含まれます。たとえば、できます。
DOMAINHTML5仕様のメールでカスタムを作成します。DOMAINチェック時にサーバーでMXレコードをチェックするカスタムを作成します。PostgreSQLに固有のこの回答でこれらのオプションを評価します