私は、名、姓、電子メール、電話番号を保存する非常に小さな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文字である必要があります。マレーシアやインドなど、一部の国では完全な形式で非常に長い名前があります。
電話番号と郵便番号always数字ではなくテキストとして扱います。与えられた通常の理由は、0で始まる郵便番号があり、国によっては電話番号も0で始まる場合があることです。しかし、本当の理由は、それらが番号ではないことです-それらは識別子であり、たまたま数字で構成されています(そして、カナダのような文字を含む国を無視しています)郵便番号)。したがって、テキストフィールドに保存します。
MySQLでは、このタイプの情報にVARCHARフィールドを使用できます。怠soundsに聞こえますが、適切な最小サイズを気にする必要はありません。
可変長のデータ(名前、電子メールアドレス)を処理するため、VARCHARを使用する必要があります。 VARCHARフィールドが占めるスペースの量は[field length]
+ 1バイト、最大長は255です。そのため、完璧なサイズを見つけようとする心配はあまりありません。予想される最長の長さを確認し、それを2倍にして、それをVARCHAR制限として設定します。とはいえ...:
私は通常、メールフィールドをVARCHAR(100)に設定します-私はまだそれから問題を思いつきませんでした。 VARCHAR(50)に設定した名前。
他の人が言ったように、電話番号と郵便番号は実際には数値ではなく、0〜9の数字(およびそれ以上の場合もあります!)を含む文字列であるため、文字列として扱う必要があります。 VARCHAR(20)で十分です。
電話番号を整数として保存する場合、多くのシステムは、0で始まる番号が8進数(基数8)であると想定することに注意してください。したがって、完全に有効な電話番号「0731602412」は、10進数「124192010」としてデータベースに入力されます!!
私も同じことをしていますが、ここに私がやったことを示します。
名前、アドレス、電子メール、および番号に個別のテーブルを使用しました。それぞれのテーブルには、NameID列があります。NameID列は、プライマリクラスタキーであるNameテーブルを除くすべての外部キーです。私は、LastNameとFirstNameの代わりにMainNameとFirstNameを使用して、ビジネスエントリと個人エントリを許可しましたが、その必要はないかもしれません。
NameID列は、すべてのテーブルでsmallintになります。これは、32000を超えるエントリを作成しないことを確信しているためです。他のほとんどすべては、保存したいもの(誕生日、コメント、メール、本当に長い名前)に応じて、20〜200の範囲のvarchar(n)です。それはあなたがどんな種類の物を保管しているかに本当に依存しています。
Numbersテーブルは、そこから逸脱した場所です。 NameID、Phone#、CountryCode、Extension、およびPhoneTypeというラベルの付いた5つの列を持つように設定しました。 NameIDについてはすでに説明しました。電話番号は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] ')。これにより、必要なものだけがデータベースに格納され、データの一貫性が維持されます。拡張機能と国コードは、nullを使用可能なsmallintと呼びましたが、必要に応じてvarcharにすることもできます。 PhoneTypeはvarchar(20)であり、nullにはできません。
お役に立てれば!