2

だから私は周りを検索しましたが、満足のいく答えは見つかりませんでした。

タイトルにあるように、私はさまざまなタイプの場所を持っています。場所のタイプ (都市など) を指定すると、より詳細でない場所を推測できます。つまり、オレゴンにいることがわかっている場合は、米国にいることを意味し、北米にいることを意味します。

場所を参照するオブジェクトがありますが、粒度はすべて同じではありません。一部のアイテムは近隣を指している可能性があり、他のアイテムは都市レベルまでしか知られていない一方で、一部のアイテムは地域のみが知っているなどです.

データの整理には 2 つの方法が考えられましたが、これは私が傾倒している方法です。

  • 場所の「タイプ」とそれ自体を参照する「親の場所」を持つ汎用の「場所」テーブルを用意します。したがって、国タイプの米国のエントリと、米国を参照するオレゴン タイプの州のエントリがあります。すなわち

ここに画像の説明を入力

次に、オブジェクトがその主キーから離れた場所を参照するようにすることができ、その後、他の場所を推測できます。これは理にかなっていますか、それともデータを整理するためのより良い方法はありますか?

  • 私が考えたもう 1 つの方法は、場所の「タイプ」ごとに異なるテーブルを使用することでしたが、オブジェクトの場所の最も細かいタイプが常に同じであるとは限らないため、オブジェクトがそれを参照することに問題がありました。

後で別の場所の種類 (たとえば、都市と地域の間の郡など) を挿入すると、問題が発生する可能性がありますか? 別のテーブルを使用するよりも問題はないと思いますが、論理的な方法で物事を追跡できるより良い方法があるかもしれません.

4

3 に答える 3

1

これは、しばしばサブタイプと呼ばれるサブクラスの場合です。一部のサブタイプが他のサブタイプに含まれているという事実によって複雑になります。コンテナーの問題は、古典的な基本的なリレーショナル データベース設計によって適切に処理されます。

サブクラスの問題については、少し説明が必要です。OOP が「サブクラス」と呼ぶものは、ER モデリング サークルでは「ER スペシャライゼーション」という名前で呼ばれます。これは、サブクラスを図式化する方法を示していますが、それらを実装する方法は示していません。

SQL テーブルにサブクラスを実装するための 2 つの手法について言及する価値があります。1 つ目は、「単一テーブル継承」という名前です。2 つ目は、「クラス テーブルの継承」という名前です。クラス テーブルの継承では、タイプに関係なく、すべての場所に共通するすべての属性を含む「場所」用の汎用テーブルが 1 つあります。「Cities」テーブルには、都市に関連する属性がありますが、国などには関連していません。他のタイプの場所には、他のサブクラス テーブルがあります。

この方法を使用する場合は、「共有プライマリ キー」と呼ばれる別の手法を調べる必要があります。この手法では、サブクラス テーブルのすべての id フィールドに、スーパークラス テーブルの id フィールドのコピーが含まれます。これには少し手間がかかりますが、それだけの価値があります。

共有主キーにはいくつかの利点があります。サブクラス関係の 1 対 1 の性質を強制します。特殊化されたデータと一般化されたデータを簡単、簡単、迅速に結合できます。追加のフィールドなしで、どのアイテムがどのサブクラスに属しているかを追跡します。

あなたの場合、さらに別の利点があります。外部キーを使用して場所を参照する他のテーブルは、スーパークラス テーブルまたはサブクラス テーブルのどちらを参照するかを決定する必要はありません。スーパークラス テーブルを参照する単一の外部キーは、サブクラス テーブルの 1 つを暗黙的に参照しますが、どのテーブルかは明らかではありません。

これは完璧ではありませんが、非常に優れています。そこに行って、それをしました。

詳細については、テクニックをググるか、SO で関連するタグを見つけることができます。

于 2012-11-07T14:18:15.287 に答える
0

どうですか：

国:

  • Id、
  • Name.

地域:

  • Id、
  • CityId、
  • Name.

都市:

  • Id、
  • RegionId、
  • Name.

近所:

  • Id、
  • CityId、
  • Name.

これは場所の種類の場合です。しかし、あなたの場合の主な問題は

しかし、粒度はすべて同じではありません。

このため：

物体：

  • Id、
  • Name、
  • LocationId、
  • Type.
于 2012-11-06T19:24:58.163 に答える
0

良い質問。

間違いなく最初のオプションを使用する必要があります。データ モデリング パターンの本を見ると、すべてその方法を選択しています。

これは北米のみですか、それともグローバルですか?

問題：

市/町/ハムレット/村は、国 (または郡) の子であるイングランドなどではありませんが、ディビジョン (州/州の総称) の子です。

郵便番号 (郵便番号、郵便番号) も、郡や市ではなく、部門の子です。一部の都市は完全にzipに存在し、一部のzipは完全に都市に存在します

郡も部門の子です。マンハッタンには郡が含まれていますが、ほとんどの郡には都市が含まれています。

グローバルなソリューションを希望する場合は、Hay の Enterprise Model Patterns をお読みください。格安でサファリです。

于 2012-11-06T20:41:44.043 に答える