私は連絡先管理システムを設計していますが、地理的な場所を一貫した方法でモデル化することに関して興味深い問題に遭遇しました。特定の人に関連付けられた場所（職場、学校、自宅などの住所）を記録できるようにしたいと思います。私の考えは、次のようなロケールのテーブルを作成することです。
自律ロケーション（米国などの国など）が自身の親であるロケール（ID、LocationName、ParentID） 。このようにして、「政治単位」を任意に深くネストすることができます（COUNTRY>STATE>CITYまたはCOUNTRY>STATE>CITY> UNIVERSITY）。一部のクエリには、必然的に再帰が含まれます。
そのような計画で遭遇する可能性のある予測可能な問題に関する他の推奨事項またはおそらくアドバイスをいただければ幸いです。
私には良いアプローチのように聞こえます。あなたの投稿を読んでいるときに私がはっきりしないことの1つは、「自分自身の親」が何を意味するかです。これがロケールに親がないことを示す場合は、それ自体のIDよりもnullを使用する方がよいでしょう。
Freebase.comを、「場所」の意味と、場所が別の場所に含まれている場合の意味についてオープンな議論が行われているサイトとしてご覧になることをお勧めします。この種の質問は、多くの議論を生み出す可能性があります。
たとえば、明白な「地理的ネスト」がありますが、それほど明白ではない論理的ネストがあります。たとえば、厳密に地理的な意味で、バチカン市国はイタリア内にネストされています。しかし、それは政治的に入れ子にされていません。同様に、ユーザーが大学に属する研究センターにいるが、大学の敷地内にいない場合、その関係をモデル化しますか？
あなたはこれを考えすぎているのではないかと思います。ほとんどのシステムが住所とおそらく国のテーブルを保存するのには理由があります。以下に、注意すべき点をいくつか示します。
ブロンクスの住所には、階層内のレベルとして行政区が含まれますか? 法人化されていない地域の住所は、階層の「都市」レベルを排除しますか? 大学内の住所と、大学内にない住所をどのようにモデル化しますか? アプリケーションで住所を表示する必要があるたびに、ツリーをトラバースする必要がある不規則な階層になってしまいます。「アドレス帳」ページがある場合、パフォーマンスへの影響が大きくなる可能性があります。
階層が 1 つしかないかどうかもわかりません。ブラウン大学にはロードアイランド州プロビデンスとロードアイランド州ブリストルに施設があります。唯一のクリーンな解決策は、1 つの階層ではそれぞれの都市に属し、もう一方の階層では両方ともブラウン大学に属する 2 つのキャンパスを持つ二重階層を持つことです。（大学は基本的に政治地域とは異なります。実際にそれらを混在させるべきではありません。）
郵便番号はどうですか？複数の町にまたがる郵便番号もあれば、都市が複数の郵便番号に分割されている場合もあります。そして (まれに) 一部の郵便番号は、州境をまたぐことさえあります。（ウィキペディアによると、少なくとも...）
どのようにデータを入力しますか？バニティアドレス、特定の通りの代替名、さまざまな国際形式などを考慮すると、従来の形式の住所を解析してデータベースを構築することは困難な場合があります。また、すべての住所を階層的に入力することは PITA になると思います。
アプリケーションで世界全体をモデル化しようとしているようです。世界のすべての都市、州、州、郵便番号、および国を含むと考えられるテーブルを本当に維持したい、または維持する必要がありますか? （または、少なくともあなたが誰かを知っているすべてのもの？）このスキームがあなたを買うと私が考えることができる唯一のことは近接性ですが、それが必要な場合は、州と国を別々に保存します（郵便番号も） Google からの緯度と経度のデータを追加します。
極端な悲観論で申し訳ありませんが、私自身その道を歩んできました。論理的には美しくエレガントですが、実際にはうまく機能しません。
これは、非常に柔軟なスキーマの提案です。即時の警告: 実際に必要なものに対して柔軟性/複雑すぎる可能性があります
Location (LocationID, LocationName) -- 基本構成要素
LocationGroup (LocationGroupID, LocationGroupName, ParentLocationGroupID) -- これにより、複数の階層を効果的にカプセル化できます。ルート ノードが 1 つあれば、複数の独立したブランチを作成できます。たとえば、最初に州ごとに分割してから、ZIP/city/xxxx などのいくつかのサブ階層を作成できます。
LocationGroupLocation (LocationID, LocationGroupID) -- Location を 1 つ以上の階層にリンクする方法は次のとおりです。たとえば、あなたの家を都市だけでなく ZIP にもリンクすることができます...実装する必要があるのは、場所を 2 つの階層の親である場所にリンクできないようにする必要があるという制約です。 other (関係はすでに暗黙的であるため)。
これは必要な機能ではない可能性があるため、慎重に検討します。テキスト フィールドを使用して、ユーザーがアドレスを入力できるようにしないのはなぜですか?
KISS の原則(Keep It Simple, Stupid) を思い出してください。
ここで要件について非常に注意する必要があるという他の投稿に同意します。場所は難しい問題になる可能性があり、これが GIS システムが非常に複雑な理由です。
基本的な階層構造だけが必要だと確信している場合は、次の提案があります。
地理的な場所については、住所を緯度、経度の配列 (おそらく Google マップなどを使用して) に解決して、近接度などを計算したい場合があります。地理的なネスティングについては、KISS 応答を使用します。
本当にモデル化したい場合は、おそらくタイプをより一般的なものにする必要があります... 国 -> 州 -> 郡 -> 自治区 -> 地域 -> 市 -> 郊外 -> 番地または私書箱 -> 番号 -> -> アパートなど -> 機関 (大学または雇用主) -> ディビジョン -> サブディビジョン-1 -> サブディビジョン-n ... 本当に KISS はできませんか?
私はグローバル ユーザー向けのアプリをモデル化していますが、同じ問題を抱えていますが、このアプローチはすでに多くの企業で使用されている可能性があると思います。しかし、なぜこの問題には普遍的な解決策がないのでしょうか? それとも、この問題は出発点となる最善の解決策の 1 つですか、それとも世界中の誰もが最初から解決策を考える必要がありますか? IT では、残念ながら、いつでもどこでも同じものを作っています。たとえば、複数のユーザー、顧客、または製品のデータベースを作成していないのは誰ですか? そして最悪なことに、世界中のすべての企業がそれを成し遂げました。普遍的な問題に対する普遍的な解決策が得られると思います。