-1

次の問題の解決策が必要です。これは、物事を複雑にすることなく、ベストプラクティスに従うことも理にかなっています。

リンクする必要のあるテーブルは、セクター、場所、会社の3つです。

つまり、会社「Bobs B＆B」は、ロケーション「ニューヨーク」にあるセクター「宿泊施設」にあります。ホテルグループの場合、複数の場所にまたがる複数のセクターに1つの会社を置くことができます。

そこで、3つのテーブルをリンクする3つの主キーを持つ「 CompanySectorLocation 」テーブルを作成することにしました。

CompanySectorLocation
    CompanyID (PK FK)
    SectorID (PK FK)
    LocationID (PK FK)

ここで曲がったボールは、場所が必要ないということです。

つまり、「ProteaHotels」は「Accomodation」セクターでアクティブであり、場所をNULLのままにします。

私の開発者は、 NULLFKを許可するテーブルを持つことに非常に反対しています。彼の提案は、場所が定義されていない会社とセクター間のリンクを処理するCompanySectorと呼ばれる別のテーブルを作成することです。

CompanySector
    CompanyID (PK FK)
    SectorID (PK FK)

これに関する私の問題は、データが効果的に複製された2つのテーブルを維持する必要があることです。

これを行うための最良の方法は何ですか？

4

1 に答える 1

0

別のテーブルを作成します。NULL FK（多くの人がそうします）に対して私は何も反対していませんが、1つのテーブルがあるということは、とにかく重複データがあることを意味します。たとえば、ボブのB＆Bがカリフォルニアに支店を開設した場合、「ボブのB＆B」と「宿泊施設」の関係を指定するエントリがテーブルに重複して表示されます。DISTINCTテーブルが1つしかないということは、CompanyID列とSectorID列のみを含むこのテーブルの結合に含める必要があることも意味します（LocationIDがnull許容の場合に発生する可能性があります）。

事実上、2つの多対多の関係があります。

(Company) <-> (Sector)

と

(Company/Sector) <-> (Location)

2つの異なる関係をモデル化するために2つのリンクテーブルを使用することは理にかなっています。（便宜上）1つのテーブルに3つのエントリすべてが必要な場合は、いつでもインデックス付きビューを作成できます。

于 2012-06-11T16:53:01.623 に答える