4

アプリケーションを作成するたびに、システムのアドレスを格納する「アドレス」テーブルを作成していることに気づきます。

「アドレス」テーブル (複数のアドレスを正規化する場合はテーブル) 内にどの列を作成し、その背後にある理由は何ですか?

4

3 に答える 3

4
  • ライン1
  • 2行目
  • 3行目
  • 地方
  • 領域
  • 郵便番号
  • 国 (国テーブルへの外部キー)

国を除いて、これらのフィールドはすべてテキスト (varchar) です。

これは、受信者が別の場所に保存されていることを前提としています。

たとえば、行の1つを失い、次のように置き換えることも適切です。

  • 街路番号
  • 道の名前

これは、検証や Web サービス経由でのアドレスの検索などに役立つためです。

于 2009-09-11T02:14:38.123 に答える
2

「場合による」という回答を差し上げます。アプリケーションが適切に印刷された住所ラベルのレイアウトだけに関心がある場合は、一連の行 (line1、line2、line3 など) で十分です。データの入力方法によっては、テキスト BLOB も機能する場合があります。ユーザーにボックスを与えて入力させますか? 3、4、5行に収まるようにしますか？なんでもいい。

ただし、郵便番号で並べ替えたり、都市、州、国ごとに分布を分析したり、番地 (10 Main St. vs. 54321 Main St.) の場合、重要な情報ごとに個別の列が必要になります。

要件は「アドレス用のスペースを含める」ことである可能性が高く、アドレスで実際に何が行われるかに関する決定は後で出てくるでしょう...その時点で、ソート/カウント/指数化/何でもできるようにしたいでしょうたとえ彼らが実際にそれをしないとしても。他の投稿で参照されているリンクによると、国際的になると、実際には非常に複雑になる可能性があります. 「合理的」とは、要件の背後にあるビジネス上の理由に依存します。

于 2009-09-11T03:34:25.217 に答える
1

理想的な世界では、すべてのアプリケーションが UPU や BS7666 などの標準形式でアドレスを保存します。構造化された住所を印刷用の単一の文字列に結合する方が、後でテキストの単一の塊から住所要素を抽出するよりもはるかに簡単です。遅かれ早かれ、おそらくあなたではない誰かが、アドレス情報を使って「何かをしたい」と思うからです。最近、データ ウェアハウスは非​​常にファッショナブルです。

残念ながら、BS7666のようなものを実装するには、通常、アドレス検証ソフトウェアが必要です。locality通常のユーザーにアドレスをプロクラスの形式に合わせるように求めるのは不合理です: 彼らが a 、 a 、townおよび aの違いを理解するとは期待できませんpost town。また、標準形式として検証されていないものを標準形式であると宣伝するのは誤解を招きます。

しかし、何らかの形の構造を求めてください。また、少なくとも郵便番号/zip を正規表現で検証して、正しい形式であることを確認してください。

于 2009-09-11T05:18:36.597 に答える