自己参照テーブルの複合キー

Question

以下に定義されているサイトテーブルの複合主キーがあります。機能的には、これは私たちが望むのとまったく同じです。各サイトには同じ地区の親サイトが必要です。このようにテーブルを定義することで、特にそのことが可能になります。

CREATE TABLE [dbo].[site](
     [site_number] [nvarchar](50) NOT NULL, 
     [district_id] [bigint] NOT NULL, 
     [partner_site_number] [nvarchar](50) NULL, 
    CONSTRAINT [PK_site] PRIMARY KEY CLUSTERED 
    (
     [site_number] ASC, 
     [district_id] ASC 
    ) 

    ALTER TABLE [dbo].[site] WITH CHECK ADD CONSTRAINT [FK_site_site] FOREIGN KEY([partner_site_number], [district_id]) 

具体的な質問は、複合PKで定義された自己参照FKに関するものです。私はこの特定のデザインに関するいくつかの意見を聞いたことがあり、それらは矛盾する傾向があります。複合キーの一般的な理解の範囲内で機能するため、特に好きな人もいます。理論的には間違っており、[district_id]ではなく[partner_district_id]フィールドがFKに含まれている必要があります。この設計では、[district_id] = [partner_district_id]（チェック制約またはアプリケーション・レベル・ロジックのいずれかで実行可能）を強制するための検証が必要です。

これらの解決策またはその他の意見についてのさらなる意見は高く評価されます。

Answer 1

私はSiteIdをプライマリキーにすることをお勧めします。 DistrictIdはおそらく外来キーでしょうか？

EDIT - この場合、追加のPartnerDistrictIdを外部キーに追加することをおすすめします。あなたは後で別の地区の別のサイトと1つのサイトをパートナーしたいかもしれません。しかし、個人的には、私はここで代理キーに賛成するでしょう。ほとんどの場合;）

Answer 2

命名コメント... Site_Id自体は一意ではありませんか？ Site_idという名前はiutが存在することを意味します。それがDistrict_Idとの組み合わせでユニークな場合は、おそらくmisnamed ... site_Sequence、District_site_No、またはそれ以外のものが明確である可能性があります。

あなたのドメインモデルを理解していれば、地区内のすべてのサイトが同じルート親サイトから「派生」し、別の地区のサイトレア間に重複がない可能性があります。同じ場合は、 DistrictIDをヌル値にすることで、ルートサイト用にのみ作成できます。次に、Site_Idは単一のフィールドPKになり、ParentSiteIdは単一のField FKになります。すべての「子」サイトはルート親サイトの記録で指定された地区に「所属」します。