データベース内の電子メールアドレスの最適な長さは？
_EMAIL_ADDRESS_列のデータ型とプロパティを反映した、クエリの抽出部分を次に示します。
_EMAIL_ADDRESS CHARACTER VARYING(20) NOT NULL,
_ただし、 John Saunders はVARYING(256)を使用します。
これは、VARYINGを必ずしも正しく理解していないことを示唆しています。
私の場合、メールアドレスの長さは20文字、Jodnの場合は256文字であると理解しています。
ジョンのコードのコンテキスト
_CREATE TABLE so."User"
(
USER_ID SERIAL NOT NULL,
USER_NAME CHARACTER VARYING(50) NOT NULL,
EMAIL_ADDRESS CHARACTER VARYING(256) NOT NULL, // Here
HASHED_PASSWORD so.HashedPassword NOT NULL,
OPEN_ID CHARACTER VARYING(512),
A_MODERATOR BOOLEAN,
LOGGED_IN BOOLEAN,
HAS_BEEN_SENT_A_MODERATOR_MESSAGE BOOLEAN,
CONSTRAINT User_PK PRIMARY KEY(USER_ID)
);
_私は、普通の人々が使用する20文字を超えるメールアドレスを見たことはありません。
データベース内の電子メールアドレスの最適な長さは？
電子メールアドレスの最大長は254文字です。
すべてのメールアドレスは2つの部分で構成されています。 「@」記号の前にあるローカル部分と、それに続くドメイン部分。 「[email protected]」では、ローカル部分は「user」、ドメイン部分は「example.com」です。
ローカル部分は64文字を超えてはならず、ドメイン部分は255文字を超えることはできません。
電子メールアドレスのローカル+ @ +ドメイン部分の合計長は254文字を超えてはなりません。 RFC3696エラッタID 169 で説明されているように。
from メタフィルターに問い合わせる ：
私のデータは、323個のアドレスのデータベースから取得されます。分布には、いくつかの上限外れ値があります（積極的に歪んだ）。通常、外れ値なしで配布されます（テストしました）。
最小：12第1四分位数：19平均（外れ値なし）：23.04平均値（外れ値なし）：22.79第3四分位数：26最大（外れ値あり）：47最大（外れ値なし）：35
中央値：23モード：24標準Dev（w/outliers）：5.20標準Dev（外れ値なし）：4.70
外れ値を含むデータに基づく範囲データの68.2％17.8-28.2データの95.4％12.6-33.4データの99.7％7.4-38.6
データの外れ値に基づく範囲は、データの68.2％を除外18.1-27.5データの95.4％データの13.4-32.2 99.7％のデータ8.7-36.9
http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/ にサインアップすると、メールアドレスは必ず外れ値になります:)
ウェブサイトフォームで許可するメールアドレスの最大安全長は？ わずかに異なる平均値（N = 50,496、平均= 23）のRayconで：
varchar(50)を使用してください。長いメールは毎回くだらないです。
50文字の長さを見てください：
peoplewithanemail @ ddressthislongjustuseashorterone
255文字のメールを許可する場合：
- それらを表示すると、UIが混乱する可能性があります（せいぜい切り取られますが、最悪の場合、コンテナとマージンをプッシュします）。
- 悪意のあるユーザーは、予想できないことを行うことができます（ハッカーが無料のオンラインAPIを使用して大量のデータを保存した場合など）
（統計は、合法的な電子メールアドレスに実際に約50文字以上を入力する人はいないことを示しています。例：pageman's answer https://stackoverflow.com/a/1199245/87861 ）
データベースの可変文字タイプは、不要なスペースを占有しません。したがって、そのようなフィールドを可能な限り制約する理由はありません。個人の名前、組織で使用される命名スキーム、およびドメイン名によっては、アドレスが20文字を簡単に超えることがあります。
RFC-2822 のlocal-partおよびdomain-nameの長さに制限はありません。 RFC-2181 は、ドメイン名を255オクテット/文字に制限します。
繰り返しますが、varcharは、保存する文字列が実際に使用するスペースのみを使用するため、電子メールアドレスの長さに小さな制限を設ける理由はありません。 512を選択して心配する必要はありません。その他はすべて 時期尚早の最適化
最初の最大文字数は320文字です（他の回答に示されているように64 + 1 + 255）が、 RFC 3696 Errata 10 のように：
ただし、256文字のMAILおよびRCPTコマンドのアドレスの長さには、RFC 2821の制限があります。これらのフィールドに収まらないアドレスは通常は役に立たないため、アドレス長の上限は通常256と見なされる必要があります。
そして RFC 5321 セクションから 4.5.3.1. ：
4.5.3.1.3。道
Reverse-pathまたはforward-pathの最大合計長は256オクテットです（句読点と要素の区切りを含む）
これには、開始ブラケットと終了ブラケットが含まれているため、メールアドレスの254オクテットのみが許可されます。
ただし、オクテットの数は文字の数と等しくない場合があることに留意してください（charには2オクテット以上ある場合があります）。また、 RFCセクション4.5.3.1 は、最大値以上のフィールドが存在する可能性があることを示します。
そして、VARCHAR(254)を使用して、メールアドレスを保存する必要があります。
注：少なくともMySQLでは、255オクテット以下のVARCHARとして宣言された列はすべて1 byte + length（1は長さを格納するため）として格納されるため、使用してもスペースは取得されません。下限。
他の人が言ったように、20 + 256を超える方法は私にとって良さそうに聞こえ、RFCに準拠しています。
データベースにこのような大きな値を持たない唯一の理由は、パフォーマンスやスペースを心配している場合、そしてそれをしている場合、99.99999999999999％が時期尚早の最適化であることを確信している場合です。
大きくなる。
CHAR（20）フィールドは、すべて使用するかどうかにかかわらず、常に20文字を使用します。 （多くの場合、末尾にスペースが埋め込まれます。）VARCHAR（20）フィールドは最大 20文字を使用しますが、それより少ない場合があります。 CHAR（）の一定幅の利点の1つは、テーブル内の行にすばやくジャンプすることです。これは、インデックスをオンにするだけで計算できるためです。欠点はスペースを無駄にすることです。
テーブルにVARCHAR（x）列がある場合、一定サイズのCHAR（x）の利点は失われます。一部の列がVARCHAR（）であった場合、MySQLは背後で暗黙的にCHAR（）フィールドをVARCHAR（）に変換したことを思い出すようです。