データベースに米国の郵便番号を格納するために整数列を使用するのは良い考えですか？
一見すると、データベーステーブルに 郵便番号 を保存するための2つの基本的な選択肢があるように見えます。
- テキスト（おそらく最も一般的）、つまり+4拡張をサポートする
char(5)またはvarchar(9) - 数値、つまり32ビット整数
国際的な懸念がないと仮定すれば、どちらもデータの要件を満たします。過去には、一般的にテキストルートを使用していましたが、だれかが反対するのかと疑問に思っていましたか？簡単な比較から、整数法には2つの明らかな利点があるように見えます。
- それは、その性質上、自動的に数値のみに制限されます（検証なしでは、テキストスタイルは文字などを保存できますが、私の知る限り、郵便番号では有効ではありません）。ただし、これはdoes n'tではありませんが、ユーザー入力の検証を通常どおり検証することはできませんでした。
- スペースは少なく、5または9バイトではなく、4バイト（9桁の郵便番号でも十分）になります。
また、ディスプレイの出力をそれほど傷つけないようです。 ToString()を数値に平手打ちし、単純な文字列操作を使用してハイフンまたはスペース、または+4拡張子用のものを挿入し、文字列フォーマットを使用して先行ゼロを復元するのは簡単です。
米国のみの郵便番号のデータ型としてintを使用することを思いとどまらせるものはありますか？
数値の郵便番号は、少しだけ誤解を招きます。
数字は何かを意味する必要がありますnumeric。郵便番号は、数値演算の加算、減算、参加を行いません。 12309-12345は、スケネクタディのダウンタウンから私の近所までの距離を計算しません。
郵便番号については、混乱する人はいません。ただし、他の数字のようなフィールドの場合、混乱する可能性があります。
郵便番号は数字ではないため、たまたま制限されたアルファベットでコード化されているだけなので、数値フィールドを避けることをお勧めします。 1バイトの節約はあまり価値がありません。そして、意味はバイトよりも重要だと思います。
編集。
「先行ゼロについては...」が私のポイントです。数字に先行ゼロはありません。郵便番号に意味のある先行ゼロが存在することは、数値ではないことのもう1つの証拠です。
米国以外の郵便番号を保存する予定はありますか？カナダはいくつかの文字を含む6文字です。通常、10文字のフィールドを使用します。ディスクスペースは安価ですが、データモデルを作り直す必要はありません。
検証で文字列を使用します。郵便番号は0で始まるため、数値は適切なタイプではありません。また、これは国際郵便番号（例：最大8文字の英国）にも適用されます。郵便番号がボトルネックであるというまれなケースでは、10文字に制限できますが、最初に ターゲットフォーマット を確認してください。
ここにあります 英国、米国、カナダの検証正規表現。
はい、パッドして先行ゼロを取り戻すことができます。ただし、理論的には、エラーが発生した場合に役立つ情報を破棄しています。誰かがデータベースで1235を見つけた場合、それはもともと01235ですか、それとも別の数字が抜けていましたか？
ベストプラクティスでは、意味を言う必要があります。郵便番号は数字ではなくコードです。 add/subtract/multiply/divide 郵便番号に行きますか？また、実用的な観点からは、拡張zipを除外することがはるかに重要です。
通常、より多くの郵便番号タイプを許可するvarcharなどの非数値データタイプを使用します。 5桁の[XXXXX]または9桁の[XXXXX-XXXX]郵便番号のみを許可するように設定されている場合、char（5）またはchar（10）を使用できますが、お勧めしません。 Varcharは最も安全で最も健全な選択肢です。
編集：フィールドで数値計算を行う予定がない場合は、数値データ型を使用しないでください。郵便番号は、あなたがそれに対して加算または減算するという意味での数字ではありません。これはたまたま通常数字で構成されている単なる文字列であるため、数値データ型を使用しないでください。
技術的な観点から、ここで挙げたいくつかの点はかなり些細なことです。私はdailyに基づいて住所データのクレンジングを行っています-特に世界中の住所データをクレンジングしています。それは想像力の広がりによる些細な仕事ではありません。郵便番号になると、could整数として格納しますが、「意味的に」正しくない場合があります。実際には、データは、厳密に言えばis値が数値と見なされるかどうかにかかわらず、数値形式です。
ただし、それらを数値型として保存することの非常に本当の欠点は、データが誤って入力された（つまり値が欠落している）か、システムが先行ゼロを削除して無効な可能性を検証するためのコストのかかる操作を簡単に確認する機能を失うことですそれ以外は正しかった郵便番号。
また、影響の1つがビジネスの遅れである場合、ユーザーに正しいデータを入力させることは非常に困難です。ユーザーは、すぐに明らかでない場合は、正しいデータを入力する忍耐力がないことがよくあります。正規表現の使用は正しいデータを保証する1つの方法ですが、ユーザーが準拠していない値を入力してエラーが表示された場合、ユーザーはこの値を完全に省略したり、準拠しているが正しくないものを入力したりできます。 1つの例[カナダの郵便番号を使用]は、A0A 0A0が入力されていることがよくあります。これは有効ではありませんが、カナダの郵便番号の正規表現に準拠しています。多くの場合、これは郵便番号を提供することを余儀なくされるユーザーによって入力されますが、ユーザーはそれが何であるかを知らないか、またはすべてが正しいわけではありません。
1つの提案は、住所全体と比較して郵便番号が正しいことを検証する単位として、エントリ全体を検証することです。間違っている場合、住所に有効な別の郵便番号を指定すると、有効なデータを入力しやすくなります。同様に、郵便番号が番地に対して正しいが、番地がその郵便番号のドメインの外にある場合は、その郵便番号/番地の組み合わせに対して別の番地を提供します。
郵便番号データで数学的計算を実行するビジネス要件がない限り、INTを使用しても意味がありません。あなたはエンジニアリングを超えています。
お役に立てれば、
ビル
いいえ、なぜなら
- 郵便番号で数学関数を実行することはありません
- ダッシュを含めることができます
- 0から始めることができます
- NULL値は、整数などのスカラー型の場合にゼロと解釈される場合があります（たとえば、何らかの方法でデータをエクスポートする場合）
- 郵便番号は、それが数字であっても、エリアの指定です。これは、これが何かの数値ではなく名前であることを意味します
考えてみると、郵便番号は本当にコード化された名前空間です。伝統的に数字だけでなく、ハイフンと大文字：
「10022-SHOE」
http://www.saksfifthavenue.com/main/10022-shoe.jsp
現実的には、多くのビジネスアプリケーションは、たとえ有効であっても、このEdgeのケースをサポートする必要はありません。
Integerは素晴らしいですが、米国でしか機能しないため、ほとんどの人はそうしていません。通常、varchar（20）程度を使用します。おそらくどのロケールでもやり過ぎです。
US Zipsに整数を使用する場合、先頭部分に10,000を掛けて、+ 4を追加します。データベースのエンコードは、入力検証とは関係ありません。入力は常に有効であるかどうかを要求できますが、ストレージは、要件またはUSPSが変更されると思う程度の問題です。 （ヒント：要件will変更。）