1

現在、住所データは次のように保存されています。

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

しかし、アドレスを処理してインポートするときに、最初の5つのアドレス部分を解析するという（私が言えることから一般的な）問題に直面しています。

番地が単なる文字列（データベース内のvarchar）であれば、これらすべてが大幅に簡単になると思います。

なぜそのままにしておくべきかという2つの議論があります。1。通りの名前や番号などだけで検索できると検索が簡単になりますが、次の行に沿ったSQLスクリプトを考えています。 SELECT x FROM Address WHERE streetAddress LIKE "％INPUT％"; 確かにそれほど高速ではありませんが、機能します（そして、その検索のデータセットは顧客のみにあり、私たちが保存したすべてのアドレスのセットよりも信じられないほど小さいです）。

  1. 現在、アパートにフラグを立てるシステムがあります。住所Aの1人がアパートであることがわかった場合は、フラグを立てます。その番地/番地にいる他のすべての人を検索して、フラグを立てます（これは重要な場合があります）。ビジネスニーズ）

アドレスには無数の例外があるため、私はすでにそれらをすべて文字列として保存しています。

だから私は尋ねます、住所の部分を別々に保管する必要がある/したい特別な理由はありますか？

4

6 に答える 6

4

私はしばらく前にこれについてのブログ記事全体を書きました。各データを別々のフィールドに保存するのには非常に理由があります。特に住所データの検証用です。

もちろん、それはあなたがどの業界にいて、情報が何のために使われているのかによります。無効なアドレスデータが会社に何の費用もかからない場合は、必ず無効なデータを保存してください。ただし、将来的には、このデータを郵送や人口統計レポートなどに使用することをお勧めします。データが無効な場合は、事後に修正するのは簡単ではありません。

これが私のブログ投稿です：

http://www.endswithsaurus.com/2009/07/lesson-in-address-storage.html

また、「Where StreetAddress Like'％whatever％'」の検索を参照してください。自分の利益のためにすばやく検索する場合、これはすべてうまくいきますが、住所データに依存するシステムの部分を自動化しようとしたり、重複を削除しようとしたりする場合は、ユーザーに自動提案などを提供しますなど、パフォーマンスが低下し、アドレステーブルが大きくなると使用できなくなります。

無効なアドレスが会社に実際の現金を犠牲にする心配ではない場合、それは問題ではありません-しかし、あなたが経済的に有益な（または将来的になる可能性が高い）何かのためにアドレスを使用していない場合では、そもそもなぜその情報を保存しているのですか？

@Snorfusああ、あなたは大草原にいる必要があります。土地の説明をブログに投稿するなど見落としていましたが、後の投稿で検討しています。

リーガルサブディビジョン（LSD）は、主にアルバータ州、サスカチュワン州、マニトバ州の石油・ガスおよびその他の一次資源産業で使用されています（BCの一部でも見られますが、それほど普及していません）。それらはすべて同じ形式を取ります：セクション、タウンシップ、範囲、子午線。例えば：

SE 28-12-17-W5

これは、セクション28、タウンシップ12、レンジ17、西経5度線の西の南東の角です。

単一のフィールドを使用して正規表現で解析するか、LSDの内訳を含む個別のフィールドに分割することができます。SQL Serverで正規表現を実行すると、パフォーマンスが低下する可能性があります。私の見解は、一般的な住所データの見方と同じです。各データは個別の一意のデータであるため、個別のフィールドに格納する必要があります。ただし、このタイプの住所データの大部分はそうではありません。番地の代わりに一般の人が使用する場合は、この情報をメインの住所データから分離（ただしリンク）できるようにするものを設計することをお勧めします。ただし、土地の説明/ LSDもすべてのカナダの住所の一部であるため、データベースの対象ユーザーによっては、メインの住所テーブルに保存したくなる場合があります。

アルバータ州の土地資源システムの内訳に関する投稿は次のとおりです。

http://www1.agric.gov.ab.ca/%24department/deptdocs.nsf/all/agdex10302

少なくともOil＆Gasでよく見かけることの1つは（私の経験の大部分はここから来ています）、労働者はLSDの最初の2つの部分、つまり12の28または16の43のみを参照することが多いということです。 LSDの残りの部分は、住所の場所、つまりグランドプレーリー、フォックスクリーク、ウルフレイクなどによって暗示されます。

于 2009-10-26T18:21:35.713 に答える
2

私のアプリケーションが展開され、変更を求めるリクエストが絶え間なく流れてくるまでは、それは良い考えだと思っていました。当時、私はカナダのオンタリオ州に住んでいて、標準の住所がどのようなものか知っていると思いました。一部の顧客が私書箱と番地を1つにまとめた住所を取得するまで。その後、アルバータ州の顧客は、別の回答で言及されている構造化コードを使用し始めました。次に、ブリティッシュコロンビア州は、番地や番地がなく、サイトとコンパートメントおよび地方のルートだけが存在する場所に対処します。C4、S16RR7マウンテンビル。そして、アメリカのサプライヤーと一緒に、郵便番号の規則は窓の外に出ました。そして、時折英国の顧客がデータベースに表示され、住所について知っていると思っていたものはすべてウィンドウから消えます。通り番号のない建物名、2つの通りの名前、

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

それは作り上げられた例ですが、それらは存在します。すべての地元企業が最新の全国住所データベースを持っており、必要なのは郵便番号と家の名前または番号だけであるため、英国人はなんとかやっていくことができます。残りはデータベースから入力されます。

その住所の場合、Seething-under-Nortonにおそらく別のWaverly Crescentがあります。これが、2番目のストリート名の理由です。そして、Seething-under-Nortonは、長い間バンバリーの町に組み込まれるようになった村だったので、両方の名前が住所に含まれています。英国の住所では、存在しない自治体を取得することがよくあります。それらは、郵便システム内にのみ存在するという点で、郵便の町と見なされます。通常、名前には歴史的な根拠があります。ロンドンの住所の多くは、ロンドンを書いている人と、レイトン、サウス・ライスリップ、ヒリンドンを書いている人がいるようなものです。手紙はすべてすぐに配達されます。

したがって、ソフトウェアの機能がシステムへの外部アドレスの入力を防ぐことでない限り、これを行わないでください。

ちなみに、同じ通りにいるすべての人を通りの名前で識別するとおっしゃいました。コロラド州デンバーをチェックしたことがありますか。ここには、1マイル離れたところにある通りの名前が終わります。私はかつてリトルトン（デンバー郊外）で特定の住所を見つけようとして迷子になりましたが、他の場所にある別のそのような通りが必要だと言われただけでした。次に、すべての道路に2つ以上の名前を使用するという英国の慣習があります。たとえば、マーシュヒル、ホーマートンハイストリート、アーズウィックロード、ローワークラプトンロードという名前のホーマートンロードが1〜2kmのスペースにあります。より一般的には、ウィックの村にはノートンロードがあります。それに従うと、1〜2マイル後に、ノートンの村に入ってウィックロードにいることに気付くでしょう。

于 2009-10-26T20:03:54.290 に答える
1

私の意見では、これを行うことにはいくつかの利点がありますが、私がそれを試したすべての場合において、それを行うことのコストと複雑さは無視できる利点を上回ります。

あなたの問題の少なくとも1つは、一貫した形式で構成およびアドレス指定するすべての異なる部分を入力するようにユーザーに与えるすべての個別のフィールドを尊重するようにユーザーをトレーニング/強制することです-ほとんどの人は住所を考えていません最大5つの異なるパーツで構成されており、通常どおりに入力する可能性があります。

ですから、実際にシステムを使おうとしている人たちがいなかったら、それはおそらく良い考えです。

于 2010-12-07T13:58:51.347 に答える
0

ヨーロッパでは、番地は通常、名前に「番号」を加えたものです（番号は「3a」のようになります）。単一の理由でそれらを別々に保存するデータベースを見てきました。公式データベースで通りの名前を調べて確認することができます（たとえば、タイプミスから保護するため）。したがって、このユースケースでは、検証可能な部分と検証不可能な部分を異なる列に保持するのが理にかなっています。

情報を失うかもしれないというあいまいな恐れを除いて、それをさらに分解する理由を見つけることができるとは思えません。

于 2009-10-26T18:25:02.773 に答える
0

ドメイン全体をモデル化するためにオブジェクト指向のアプローチに従っている場合に役立ちます。あなたの質問は私にこのブログタイトル3月が答えとして数ではないことを思い出させ ます。通りや住所については、似たようなものがあります（「通りは文字列ではありません」）。SnOrfusは、彼のコメントに有効な問題があることを指摘しています。

于 2009-10-26T19:58:06.390 に答える
0

アドレスの各コンポーネントを個別に保存することには利点があるかもしれませんが、ビジネスのニーズと要件に対してコストを比較検討する必要があります。郵送や発送に関連することを何もしていない場合、それはやり過ぎであり、アーキテクチャの側面を大幅に複雑にする可能性があります。さらに、あなたのコードで作業している他の人は、何が起こっているのかを理解できず、気付かないうちに重大な問題を引き起こし、データベースを破壊する可能性があります。

例として、米国内では、以下は通りの「配達ライン」です：私書箱12345。

この場合、「私書箱」は実際には通りの名前であり、12345は主要な番号です。通常の「フォーマット」と従来の知識では、「123 Main Street」のように、アドレスの最初にプライマリ番号をリストする必要があります。

標準的な方法でアドレスを一緒にフォーマットし直す場合は、アドレスが元々どのように見えたかを覚えておく必要があります。

ここで、アドレスの検証と標準化が行われます。少なくとも米国と、英国を含む他のいくつかの国では、クリーンで標準化できるオンラインアドレス検証サービスにアドレスを送信できるという利点があります。 、およびアドレスを確認します。多くの場合、これらのサービスは、住所の構成要素だけでなく、郵便物に表示されるはずの住所を返します。コンポーネントのビジネスニーズがある場合は、それらを個別に保存できます。それ以外の場合は、アドレス検証Webサービスをもう一度呼び出すと、目的の時間にコンポーネントが再度生成されます。

完全な開示のために、私はSmartyStreetsの創設者です。CASS認定の住所検証を含む米国ベースの住所検証サービスを提供しています。ご不明な点がございましたら、個人的にご連絡いただければ幸いです。

于 2011-10-13T03:40:15.877 に答える