1

場所をテーブルに保存することを目指していますが、ある場所を保存するだけでなく、別の場所にもリンクしたいと考えています。

例: "Palm Beach" という値で、これを "Florida" と "USA" にリンクして住所を作成します。

Palm Beach, Florida, USA

アイデア番号1 国、都市、町などを保持する1つのテーブルですが、「親」にリンクしています。

CREATE TABLE location {
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
parentid          
FOREIGN KEY parentid REFERENCES Employee (EmployeeID),
name VARCHAR (100) NOT NULL UNIQUE,
loc VARCHAR (17) NOT NULL,
rad VARCHAR (17),
added DATETIME DEFAULT NOT NULL
};

アイデア 2: 同じシステムだが、レベルごとに別のテーブルを使用する

CREATE TABLE locality (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR (100) NOT NULL UNIQUE,
loc VARCHAR (17) NOT NULL,
rad VARCHAR (17),
added DATETIME DEFAULT NOT NULL,
FOREIGN KEY id REFERENCES administrative_area_level_1 (administrative_area_level_1),
};

CREATE TABLE administrative_area_level_1 (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR (100) NOT NULL UNIQUE,
loc VARCHAR (17) NOT NULL,
rad VARCHAR (17),
added DATETIME DEFAULT NOT NULL,
FOREIGN KEY id REFERENCES administrative_area_level_2 (administrative_area_level_2),

);

CREATE TABLE administrative_area_level_2 (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
name VARCHAR (100) NOT NULL UNIQUE,
loc VARCHAR (17) NOT NULL,
rad VARCHAR (17),
added DATETIME DEFAULT NOT NULL
);

ある出発点から構造全体を取得できるようにしたいのです。たとえば、「パーム ビーチ」を検索して、それが米国からのものであることを取得できるようにしたいと考えています。

これに対する最善のアプローチについて誰かが私に意見を与えることができますか?

編集:これは私が使用したい構造だと思います: https://stackoverflow.com/a/317536/1738522

4

2 に答える 2

1

これに対する簡単な答えは、ネストされたセット モデルを使用して、この正確な問題 (階層に配置された地理的領域) に対処したことです (詳細については、http://mikehillyer.com/articles/managing-hierarchical-data-in-を参照してください)。 mysql/ )

より長い答えは、「n」レベルに簡単に拡張できず、レベル n からレベル 1 への単純なルートがないため、レベルごとに個別のテーブルを作成するべきではないということです。このため、アイデア #1 は追求し、詳しく説明する必要があります。

疑問がある場合は、座って、テーブル構造をどれだけ複製しているかを確認してください。テーブル構造を完全に複製した場合、重複は同じデータを格納していることを示しているため、(通常) 別のテーブルにするべきではありません。代わりに、それを単一のテーブルに格納する方法を考えてください。

私の「地域」テーブル内には、次の列があります（特に）

  • 地域ID
  • 親リージョン ID
  • 地域名
  • リフト
  • rgt

regionIDとはparentRegionID簡単に入力できます。次に、ストアド プロシージャを使用して値を生成lftします。これらの値は、リンクした記事で詳しく説明されています。rgt

直接のparentIDを格納する利点は、ツリーをより簡単に操作できることです。ただし、これを行う必要はなく、ツリーノードを追加/移動/削除する手順を簡単に保存lftして使用できますrgt

lft/rgt を使用すると、それ自体に n 個の結合を持たなくても、ツリーの上下に親/子を簡単にトラバーサル/取得できます。

于 2013-08-14T08:44:23.097 に答える
0

人々は非常に長い間、アドレスを大規模でフラットなテーブルに格納してきましたが、それには正当な理由があります。それらは扱いが非常に面倒であり、求める理論的な階層構造は現実世界のデータでは実現できません。

たとえば、「パーム ビーチ」という都市が 1 つあると、州を簡単に関連付けることができますが、「ロンドン」、「オックスフォード」、「スプリングフィールド」などの名前の都市はいくつあるでしょうか。非常に多く、もちろんさまざまな州にあります。そのため、都市の名前が「オックスフォード」であることを知っているだけでは、それを識別するのに十分ではありません。それは、州のコンテキストでのみ一意です。

郵便番号の境界も別の問題です。5 桁の郵便番号のすべてが 1 つの州内にあるわけではありません。そのため、郵便番号を 1 つの州の子として定義することはできません。

国際化の問題は言うまでもありません。

残念ながら、あなたはすでに解決された問題に対して新しい解決策を考え出そうとしています。

于 2013-08-14T09:16:51.327 に答える