56

一見すると、データベーステーブルに郵便番号を保存するための2つの基本的な選択肢があるように見えます。

  1. テキスト（おそらく最も一般的）、つまりchar(5)+4varchar(9)拡張子をサポートする
  2. 数値、つまり32ビット整数

国際的な懸念がないと仮定した場合、どちらもデータの要件を満たします。以前は、通常、テキストルートを使用していましたが、誰かが反対のことをしているのではないかと思いました。簡単に比較すると、整数法には2つの明らかな利点があるように見えます。

  • その性質上、自動的に数値のみに制限されます（一方、検証なしでは、テキストスタイルは、私の知る限り、郵便番号では有効ではない文字などを格納できます）。ただし、これは、ユーザー入力の検証を通常どおりに行うことができる、または行わない、または行わないようにする必要があるという意味ではありません。
  • 5バイトや9バイトではなく、4バイト（9桁の郵便番号でも十分なはずです）であるため、必要なスペースが少なくて済みます。

また、ディスプレイの出力をそれほど損なうことはないようです。ToString()数値を平手打ちし、単純な文字列操作を使用してハイフンやスペースなどを+4拡張子に挿入し、文字列フォーマットを使用して先行ゼロを復元するのは簡単です。

int米国のみの郵便番号のデータ型として使用することを思いとどまらせるものはありますか？

4

12 に答える 12

133

数値の郵便番号は、少しは誤解を招く恐れがあります。

数字は数値を意味する必要があります。郵便番号は、数値演算に加算、減算、または参加しません。12309-12345は、スケネクタディのダウンタウンから私の近所までの距離を計算しません。

確かに、郵便番号については、誰も混乱しません。ただし、他の数値のようなフィールドの場合、混乱する可能性があります。

郵便番号は数字ではないので（たまたま制限されたアルファベットでコード化されているだけです）、数値フィールドは避けることをお勧めします。1バイトの節約はあまり価値がありません。そして、その意味はバイトよりも重要だと思います。

編集します。

「先行ゼロについては...」が私のポイントです。数値には先行ゼロはありません。郵便番号に意味のある先行ゼロが存在することは、それらが数値ではないことのさらに別の証拠です。

于 2009-05-21T15:15:57.343 に答える
25

米国以外の郵便番号を保存する予定はありますか？カナダは6文字で、いくつかの文字が含まれています。私は通常、10文字のフィールドを使用します。ディスク容量は安価ですが、データモデルを作り直す必要はありません。

于 2009-05-21T15:12:29.567 に答える
18

検証で文字列を使用します。郵便番号は0で始まる可能性があるため、数値は適切なタイプではありません。また、これは国際郵便番号（たとえば、最大8文字の英国）にも適切に適用されます。万が一、郵便番号がボトルネックになる場合は、10文字に制限できますが、最初にターゲット形式を確認してください。

英国、米国、カナダの検証正規表現は次のとおりです。

はい、先行ゼロを取り戻すためにパッドを入れることができます。ただし、理論的には、エラーが発生した場合に役立つ可能性のある情報を破棄していることになります。誰かがデータベースで1235を見つけた場合、それは元々01235ですか、それとも別の数字が欠落していますか？

ベストプラクティスでは、意味を言う必要があります。郵便番号はコードであり、数字ではありません。郵便番号を加算/減算/乗算/除算しますか？また、実用的な観点からは、拡張zipを除外することがはるかに重要です。

于 2009-05-21T15:12:50.407 に答える
9

通常、より多くの郵便番号タイプを許可するvarcharなどの非数値データ型を使用します。5桁の[XXXXX]または9桁の[XXXXX-XXXX]の郵便番号のみを許可することに完全に固執している場合は、char（5）またはchar（10）を使用できますが、お勧めしません。Varcharは、最も安全で最も正しい選択です。

編集：フィールドで数値計算を行う予定がない場合は、数値データ型を使用しないことにも注意してください。郵便番号は、加算または減算するという意味での数値ではありません。これは、通常は数値で構成されている単なる文字列であるため、数値データ型を使用しないでください。

于 2009-05-21T15:14:28.873 に答える
7

技術的な観点から、ここで提起されたいくつかのポイントはかなり些細なことです。私は毎日アドレスデータのクレンジングを行っています。特に、世界中のアドレスデータをクレンジングしています。想像力を働かせても、それは簡単なことではありません。郵便番号に関しては、「意味的に」正しくない場合もありますが、整数として格納できます。実際のところ、データは、厳密に言えば、値が数値であると見なされるかどうかに関係なく、数値形式です。

ただし、それらを数値タイプとして保存することの非常に現実的な欠点は、データが正しく入力されていないか（つまり、値が欠落しているか）、またはシステムが先行ゼロを削除して、潜在的に無効なものを検証するためのコストのかかる操作につながるかどうかを簡単に確認できないことです。それ以外の場合は正しい郵便番号。

また、影響の1つがビジネスの遅延である場合、ユーザーに正しいデータの入力を強制することは非常に困難です。すぐにわからない場合、ユーザーは正しいデータを入力する忍耐力がないことがよくあります。正規表現を使用することは正しいデータを保証する1つの方法ですが、ユーザーが準拠していない値を入力してエラーが表示された場合は、この値を完全に省略したり、準拠しているが正しくないものを入力したりすることがあります。[カナダの郵便番号を使用する]1つの例は、有効ではないがカナダの郵便番号の正規表現に準拠しているA0A0A0が入力されているのをよく目にすることです。多くの場合、これは郵便番号を提供することを余儀なくされているユーザーによって入力されますが、彼らはそれが何であるかを知らないか、すべてが正しくないかのどちらかです。

1つの提案は、エントリ全体を1つの単位として検証し、住所の残りの部分と比較したときに郵便番号が正しいことを検証することです。正しくない場合は、住所に代替の有効な郵便番号を提供すると、有効なデータを入力しやすくなります。同様に、郵便番号が番地に対して正しいが、番地がその郵便番号のドメイン外にある場合は、その郵便番号と番地の組み合わせに対して別の番地を提供します。

于 2009-05-21T15:54:19.607 に答える
5

いいえ、

  • 郵便番号で数学関数を実行することはありません
  • ダッシュを含めることができます
  • 0から始めることができます
  • 整数のようなスカラー型の場合（たとえば、データを何らかの方法でエクスポートする場合）、NULL値がゼロと解釈されることがあります。
  • 郵便番号は、たとえそれが数字であっても、領域の指定です。つまり、これは数値ではなく名前です。
于 2016-03-21T18:54:18.757 に答える
2

郵便番号データに対して数学計算を実行するビジネス要件がない限り、INTを使用しても意味がありません。あなたはエンジニアリングを超えています。

お役に立てれば、

明細書

于 2009-05-21T16:10:02.570 に答える
1

あなたがそれについて考えるならば、郵便番号は実際にはコード化された名前空間です。従来は数字ですが、ハイフンと大文字もあります。

「10022-SHOE」

http://www.saksfifthavenue.com/main/10022-shoe.jsp

現実的には、多くのビジネスアプリケーションは、たとえそれが有効であっても、このエッジケースをサポートする必要はありません。

于 2010-05-08T20:11:32.313 に答える
0

US Zipに整数を使用する場合は、先頭部分に10,000を掛けて、+4を加算します。データベースのエンコーディングは、入力の検証とは何の関係もありません。入力が有効かどうかはいつでも要求できますが、ストレージは、要件またはUSPSがどれだけ変更されると思うかによって異なります。（ヒント：要件は変更されます。）

于 2010-01-13T09:14:38.527 に答える
0

整数は素晴らしいですが、それは米国でのみ機能します。そのため、ほとんどの人はそれを行いません。通常、私はvarchar（20）かそこらを使用します。おそらくどのロケールでもやり過ぎでしょう。

于 2009-05-21T15:14:18.000 に答える
0

最近、Rubyでこれを避けたい理由の1つは、先行ゼロで始まる郵便番号がいくつかあるためです。これは、整数として格納されている場合、自動的に8進数に変換されます。

ドキュメントから：

特別な接頭辞を使用して、10進数、16進数、8進数、または2進数の形式で数値を書き込むことができます。10進数の場合は接頭辞0dを使用し、16進数の場合は接頭辞0xを使用し、8進数の場合は接頭辞0または0oを使用します…</ p>

于 2018-02-24T16:48:54.873 に答える
0

intデータ型の郵便番号がMLモデルに影響を与える可能性があると思います。おそらく、コードが高いほど、計算用のデータに外れ値が作成される可能性があります

于 2022-03-04T12:15:37.260 に答える