文字列としてではなく、番地データを明確に保存することには利点がありますか？

Question

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

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つのアドレス部分を解析するという（私が知ることができるものから共通の）問題に直面しています。

番地が単なる文字列（dbのvarchar）である場合、このすべてが非常に簡単になると考えています。

これをそのままにしておくべき理由については、2つの議論があります。 1.通りの名前や番号などを検索できる場合は検索が簡単ですが、SELECT x FROM Address WHERE streetAddress LIKE＆quot;％ INPUT ％の行に沿ったSQLスクリプト＆quot ;;確かに高速ではありませんが、動作します（そして、その検索のデータセットは顧客のみに保存されており、保存したすべてのアドレスのセットよりも信じられないほど小さいです。）

2. 現在、アパートにフラグを立てるシステムがあります-アドレスAの1人がアパートであることがわかった場合、それらにフラグを立てます。 時々ビジネス上の重要なニーズ）

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

だから、住所の部分を別々に保存する必要がある/望まない特別な理由はありますか？

Answer 1

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

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

ここに私のブログ投稿があります：

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

また、＆quot; Where StreetAddress Like '％whatever％'＆quot;の検索に関して。あなた自身の利益のためにクイック検索をしている場合、これはすべてうまくいきますが、アドレスデータに依存するシステムの部分を自動化しようとしたり、重複を削除しようとする場合、ユーザーに自動提案などを提供しますなど、アドレステーブルが大きくなると使用できなくなるほどパフォーマンスが低下します。

無効な住所が会社の現金にかかる心配がない場合、それは問題ではありません-しかし、財政的に有益なものにアドレスを使用していない場合（または未来）、なぜその情報を最初に保存するのですか？

@Snorfus ああ、大草原にいる必要があります。私は私のブログ投稿に土地の説明についての投稿を含めることを見落としていましたが、それは後の投稿のために検討しているものです。

Legal Subdivisions（LSD）は、主にOil＆amp;で使用されます。アルバータ州、サスカチュワン州、マニトバ州のガスおよびその他の一次資源産業（B.C.の一部でも見られますが、そのような一般的な使用法ではありません）。それらはすべて同じ形式を取ります：セクション、タウンシップ、範囲、子午線。例：

  

SE 28-12-17-W5

これは、第5子午線の西、セクション28、タウンシップ12、範囲17の南東の角です。

単一のフィールドを使用して正規表現で解析するか、LSDの内訳を含む別のフィールドに分割することができます。 SQL Serverで正規表現を実行すると、パフォーマンスの面で苦痛になる場合があります。私の考え方は、一般に住所データの考え方と同じです。これは、各データが個別のフィールドに格納される個別の一意のデータであるためです。ただし、このタイプの住所データの大部分は、番地の代わりに一般大衆によって使用されていないため、この情報を分離できるものを設計することをお勧めします（ただし、リンク先）メインの住所データ。ただし、土地の説明/ LSDもカナダのすべての住所の一部であるため、データベースの対象読者に応じて、メインの住所テーブルに格納するように誘惑される可能性があります。

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

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

Oil＆amp;でよく見かけるものの1つ少なくとも（これは私の経験の大部分が由来します）労働者はしばしばLSDの最初の2つの部分、つまり12の28または16の43のみを参照することです。LSDの残りは住所の地域-グランドプレーリー、フォックスクリーク、ウルフレイクなど

Answer 2

以前は、アプリケーションがデプロイされ、変更の要求が絶え間なく流れてくるまで、これは良い考えだと思っていました。当時、私はカナダのオンタリオ州に住んでいて、標準的な住所がどのようなものかを知っていると思っていました。一部の顧客がP.O.を組み合わせた住所を持つまでボックスと住所を1つにまとめます。その後、アルバータ州の顧客は、別の回答で言及されている構造化コードを使い始めました。次に、ブリティッシュコロンビア州は、通りや通りの番号がなく、サイトとコンパートメントと田舎のルートがある場所に住所を指定します。 C4、S16 RR7マウンテンビル。そして、アメリカのサプライヤでは、郵便番号のルールが外に出ました。そして、ときどきイギリスの顧客がデータベースに登場し、住所について知っていたと思っていたすべてが消えてしまいます。番地のない建物名、2つの街路名、2つの町名をすべて1つの住所に！

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

これは構成例ですが、実際に存在します。すべての地元企業には最新の住所データベースがあり、必要なのは郵便番号と家の名前または番号だけであるため、イギリス人はうまくやっていくことができます。残りはデータベースから入力されます。

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

だからあなたのソフトウェアの機能がシステムへの外部アドレス入力を防ぐということでない限り、これをしないでください！

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

Answer 3

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

あなたの問題の少なくとも1つは、一貫した形式で構成および対処するすべての異なる部分を入力するためにユーザーに与えるすべての別個のフィールドを尊重するようにユーザーを訓練/強制することです-ほとんどの人は考えていません住所は最大5つの異なる部分で構成されており、通常のように入力するだけです。

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

Answer 4

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

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

Answer 5

ドメイン全体をモデル化するためにオブジェクト指向アプローチを採用している場合、利点があります。あなたの質問はこのブログのタイトルを思い出させます 3月は答えではありません。道路や住所についての類似物があります（「道路は文字列ではありません」）。 SnOrfusは彼のコメントに有効な問題を指摘しています。

Answer 6

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

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

この場合、「私書箱」は実際には通りの名前ですが、12345はプライマリ番号です。通常の「フォーマット」また、「123 Main Street」のように、住所の最初の番号を最初にリストする必要があると一般的に知られています。

標準的な方法でアドレスをフォーマットし直す場合、元のアドレスの外観を覚えておく必要があります。

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

完全な開示のために、私はSmartyStreetsの創設者です。米国ベースの住所確認サービスを提供しています。これには CASS認定の住所。質問がある場合は、個人的に私に連絡してください。