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