姓、名、電子メール、電話番号を格納する非常に小さなMySQLデータベースをセットアップしていて、各フィールドの「完全な」データ型を見つけるのに苦労しています。完璧な答えなどないことを知っていますが、これらのような一般的に使用されるフィールドには、ある種の共通の規則があるはずです。たとえば、フォーマットされていない米国の電話番号は大きすぎて、unsigned intとして格納できないと判断しました。少なくともbigintである必要があります。
他の人もこれが役立つと思うので、質問を上記のフィールドだけに限定したくない。
一般的なデータベースフィールドにはどのデータ型が適していますか？電話番号、メールアドレス、住所などのフィールド？
回答:
誰かがこれよりもはるかに優れた答えを投稿しようとしていますが、主に次の理由により、個人的には電話番号をあらゆる種類の整数フィールドに格納しないことを強調したかっただけです。
一般的に、しかし、私はほぼ独占的に使用するようです：
もちろん例外はありますが、ほとんどの場合をカバーしています。
ここに私が使用するいくつかの一般的なデータ型があります（私はあまりプロではありません）：
| Column | Data type | Note
| ---------------- | ------------- | -------------------------------------
| id | INTEGER | AUTO_INCREMENT, UNSIGNED |
| uuid | CHAR(36) | or CHAR(16) binary |
| title | VARCHAR(255) | |
| full name | VARCHAR(70) | |
| gender | TINYINT | UNSIGNED |
| description | TINYTEXT | often may not be enough, use TEXT
instead
| post body | TEXT | |
| email | VARCHAR(255) | |
| url | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT |
| salt | CHAR(x) | randomly generated string, usually of
fixed length (x)
| digest (md5) | CHAR(32) | |
| phone number | VARCHAR(20) | |
| US zip code | CHAR(5) | Use CHAR(10) if you store extended
codes
| US/Canada p.code | CHAR(6) | |
| file path | VARCHAR(255) | |
| 5-star rating | DECIMAL(3,2) | UNSIGNED |
| price | DECIMAL(10,2) | UNSIGNED |
| date (creation) | DATE/DATETIME | usually displayed as initial date of
a post |
| date (tracking) | TIMESTAMP | can be used for tracking changes in a
post |
| tags, categories | TINYTEXT | comma separated values * |
| status | TINYINT(1) | 1 – published, 0 – unpublished, … You
can also use ENUM for human-readable
values
| json data | JSON | or LONGTEXT 私の経験では、姓/名フィールドは少なくとも48文字にする必要があります。マレーシアやインドなどの一部の国では、完全な形式で非常に長い名前があります。
電話番号と郵便番号は、番号ではなく常にテキストとして扱う必要があります。与えられた通常の理由は、0で始まる郵便番号があることです。一部の国では、電話番号も0で始まることがあります。しかし、本当の理由は、それらが番号ではないことです。これらはたまたま作成された識別子です数字の数字の（そしてそれは彼らの郵便番号に文字を持っているカナダのような国を無視している）したがって、それらをテキストフィールドに格納します。
MySQLでは、このタイプの情報にVARCHARフィールドを使用できます。それは怠惰に聞こえますが、それはあなたが適切な最小サイズについてあまり心配する必要がないことを意味します。
VARCHAR(255)は理にかなっています。
可変長のデータ（名前、電子メールアドレス）を処理するため、VARCHARを使用する必要があります。VARCHARフィールドが占めるスペースの量は[field length]+ 1バイトであり、最大長は255であるため、完璧なサイズを見つけることについてあまり心配する必要はありません。最長と思われるものを見て、それを2倍にしてVARCHARの制限として設定します。それは言った...：
私は通常、電子メールフィールドをVARCHAR（100）に設定します-そのため、まだ問題は発生していません。VARCHAR（50）に設定した名前。
他の人が言ったように、電話番号と郵便番号は実際には数値ではなく、0〜9の数字（場合によってはそれ以上）を含む文字列であるため、文字列として扱う必要があります。VARCHAR（20）で十分です。
電話番号を整数として格納する場合、多くのシステムでは、0で始まる数値が8進数（8を基数とする）であると想定します。したがって、完全に有効な電話番号「0731602412」は、10進数「124192010」としてデータベースに入れられます。
私は同じことをやっていて、これが私がしたことです。
名前、住所、電子メール、および数値に個別のテーブルを使用し、それぞれにNameID列があり、クラスター化された主キーであるNameテーブル以外のすべての外部キーです。LastNameとFirstNameの代わりにMainNameとFirstNameを使用して、ビジネスエントリと個人エントリを許可しましたが、その必要がない場合もあります。
NameID列はすべてのテーブルでsmallintになります。これは、32,000を超えるエントリを作成しないことをかなり確信しているためです。それ以外のほとんどすべては、保存したいもの（誕生日、コメント、電子メール、本当に長い名前）に応じて、20〜200の範囲のvarchar（n）です。それは本当にあなたがどんなものを保存しているのかに依存しています。
数値表は、私がそこから逸脱している場所です。NameID、Phone＃、CountryCode、Extension、PhoneTypeという5つの列があるように設定しました。NameIDについてはすでに説明しました。Phone＃はvarchar（12）で、チェック制約は次のようになります。CHECK（Phone＃like '[0-9] [0-9] [0-9]-[0-9] [0-9] [0 -9]-[0-9] [0-9] [0-9] [0-9] '）。これにより、必要なものだけがデータベースに入り、データの一貫性が保たれます。拡張子と国コードはnullable smallintsと呼んでいましたが、必要に応じてvarcharにすることもできます。PhoneTypeはvarchar（20）であり、nullにすることはできません。
お役に立てれば！