データベースフィールドの標準長のリスト

私はデータベーステーブルを設計していて、もう一度同じ愚かな質問をします。

名、姓、電子メールアドレスなど、最も一般的なフィールドの妥当な長さのリストを持っている人はいますか？

W3Cの推奨事項：

さまざまな背景を持つ人々からの名前を受け入れるフォームまたはデータベースを設計する場合は、名と姓のフィールドを別々にする必要があるかどうかを自問する必要があります。

…一部の文化では、名前が自分の名前よりもかなり長くなる可能性があることに注意してください。… データベース内の名前のフィールドサイズを制限しないでください。特に、UTF-8の4文字の日本語名が4バイトに収まると想定しないでください。実際には12文字が必要になる可能性があります。

https://www.w3.org/International/questions/qa-personal-names

データベースフィールドの場合、VARCHAR(255)実際に他の何かを使用する十分な理由が考えられない限り、これは安全なデフォルトの選択です。一般的なWebアプリケーションの場合、パフォーマンスは問題になりません。時期尚早に最適化しないでください。

アメリカの何百万人もの顧客にデータベースを問い合わせたところです。

• 名の最大長は46でした。50を使用します。（もちろん、そのうち25を超えていたのは500だけでした。これらはすべて、データインポートによってそのフィールドで余分なジャンクが発生するケースでした。）

• 姓は名に似ていました。

• 最大62文字のメールアドレス。より長いもののほとんどは、実際にはセミコロンで区切られた電子メールアドレスのリストでした。

• 住所は最大95文字です。長いものはすべて有効でした。

• 最大都市長は35でした。

これは、米国の人々にとってまともな統計的広がりになるはずです。ローカリゼーションを検討している場合、数値は大幅に異なる可能性があります。

英国政府データ標準カタログは、この種の事柄に関する英国の標準を詳述しています。名と姓のそれぞれに35文字、またはフルネームを保持する単一のフィールドに70文字、電子メールアドレスに255文字を推奨しています。そのことなど..

おそらく正しい列の長さ

                            Min Max

Hostname                    1   255
Domain Name                 4   253
Email Address               7   254
Email Address [1]           3   254
Telephone Number            10  15      
Telephone Number [2]        3   26  
HTTP(S) URL w domain name   11  2083        
URL [3]                     6   2083    
Postal Code [4]             2   11
IP Address (incl ipv6)      7   45
Longitude                   numeric 9,6
Latitude                    numeric 8,6
Money[5]                    numeric 19,4

[1] Allow local domains or TLD-only domains
[2] Allow short numbers like 911 and extensions like 16045551212x12345
[3] Allow local domains, tv:// scheme
[4] http://en.wikipedia.org/wiki/List_of_postal_codes. Use max 12 if storing dash or space
[5] http://stackoverflow.com/questions/224462/storing-money-in-a-decimal-column-what-precision-and-scale

個人名に対する長い怒り

個人名は、Polynym（並べ替え可能な複数のコンポーネントを持つ名前）、Mononym（1つのコンポーネントのみを持つ名前）、またはPictonym（写真で表される名前-これはPrinceのような人々のために存在します）のいずれかです。

人は複数の名前を持つことができ、LEGAL、MARITAL、MAIDEN、PREFERRED、SOBRIQUET、PSEUDONYMなどの役割を果たします。一度に」。

いくつかの例：

names: [
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"George",
    middle:"Herman",
    moniker:"Babe",
    surname:"Ruth",
    generation:"JUNIOR"
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"The Bambino" /* mononyms can be more than one word, but only one component */
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"The Sultan of Swat"
  }
]

または

names: [
  {
    type:"POLYNYM",
    role:"PREFERRED",
    given:"Malcolm",
    surname:"X"
  },
  {
    type:"POLYNYM",
    role:"BIRTH",
    given:"Malcolm",
    surname:"Little"
  },
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Malik",
    surname:"El-Shabazz"
  }
]

または

names:[
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Prince",
    middle:"Rogers",
    surname:"Nelson"
  },
  {
    type:"MONONYM",
    role:"SOBRIQUET",
    mononym:"Prince"
  },
  {
    type:"PICTONYM",
    role:"LEGAL",
    url:"http://upload.wikimedia.org/wikipedia/en/thumb/a/af/Prince_logo.svg/130px-Prince_logo.svg.png"
  }
]

または

names:[
  {
    type:"POLYNYM",
    role:"LEGAL",
    given:"Juan Pablo",
    surname:"Fernández de Calderón",
    secondarySurname:"García-Iglesias" /* hispanic people often have two surnames. it can be impolite to use the wrong one. Portuguese and Spaniards differ as to which surname is important */
  }
]

与えられた名前は、ミドルネームは、姓のような複数の単語ことができ"Billy Bob" Thornton、またはRalph "Vaughn Williams"。

私はハイサイドで誤解すると言うでしょう。おそらくvarcharを使用することになるため、許可された余分なスペースは、誰かが必要としない限り、実際には余分なスペースを使い果たしません。名前（最初または最後）には50文字以上、メールアドレスには128文字以上にします。非常に長いメールアドレスがいくつかあります。

私がやりたいもう1つのことは、Lipsum.comにアクセスして、テキストを生成するよう依頼することです。そうすることで、100バイトがどのように見えるかを正確に把握できます。

私は、他の数値が顧客にとって特別な意味を持つ顧客向けのインターフェイスなど、適切な理由がない限り、ほとんど常に2の累乗を使用します。

2の累乗に固執する場合は、一般的なサイズの制限されたセット内に収まります。これ自体は良いことであり、未知のオブジェクトのサイズを簡単に推測できるようになります。私はこれをしている他の多くの人々を見ています、そしてそれについて審美的に楽しいものがあります。これを見ると一般的に良い感じがします。それは、デザイナーがエンジニアや数学者のように考えていたことを意味します。素数だけが使用されているかどうかはおそらく心配でしょう。:)

私は同じものを見つけたかったし、受け入れられた回答で言及された英国政府のデータ基準は理想的に聞こえた。しかし、これらはもう存在していないようです-拡張検索の後で、私はここのアーカイブでそれを見つけました：http : //webarchive.nationalarchives.gov.uk/+/http : //www.cabinetoffice.gov.uk/govtalk/ schemasstandards / e-gif / datastandards.aspx。zipをダウンロードして解凍し、htmlフォルダーのdefault.htmを開く必要があります。

これらは誰かに役立つかもしれません。

youtube max channel length = 20
facebook max name length   = 50
twitter max handle length  = 15
email max length           = 255 

http://www.interoadvisory.com/2015/08/6-areas-inside-of-linkedin-with-character-limits/

+------------+---------------+---------------------------------+
|   Field    | Length (Char) |           Description           |
+------------+---------------+---------------------------------+
|firstname   | 35            |                                 |
|lastname    | 35            |                                 |
|email       | 255           |                                 |
|url         | 60+           | According to server and browser |
|city        | 45            |                                 |
|address     | 90            |                                 |
+------------+---------------+---------------------------------+

編集：間隔を追加しました

私の電子メールアーカイブを見ても、かなり長い "ファースト"ネームがいくつかあります（もちろん、ファーストが意味するものは文化によって異なります）。その一例がクリシュナムマーシーで、長さは13文字です。これに基づくと、20〜25文字がよいでしょう。あなたはfirstname.lastname@somedomain.comを持っているかもしれないので、電子メールははるかに長いはずです。また、Gmailや他のいくつかのメールプログラムでは、firstname.lastname + sometag @ somedomain.comを使用できます。タグを考慮せずにメールアドレス全体を入力できないWebフォームに頻繁に出くわします。したがって、固定の電子メールフィールドが必要な場合は、25.25 + 15 @ 20.3のような文字で合計90文字にすることができます（計算を正しく行った場合）。

私は通常一緒に行きます：

名：30文字
姓：30文字
メール：50文字
アドレス：200文字

名前の長いフィールドが気になる場合は、最近ではストレージスペースの問題がほとんど発生しないため、名前フィールドにも50を使用することがあります。

ローカリゼーションを検討する必要がある場合（米国外の私たちのために！）、それがあなたの環境で可能である場合は、次のことをお勧めします。

名前の各コンポーネントのデータ型を定義します-注：一部のカルチャには3つ以上の名前があります。次に、フルネームのタイプがあります。

その後、ローカリゼーションは単純になります（名前に関する限り）。

同じことは住所、BTWにも当てはまります-異なるフォーマット！

それはvarcharですよね？したがって、50または25を使用するかどうかは問題ではありません。より安全で50を使用することをお勧めします。姓が長い