1

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

    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] を適用するための検証が必要になります。これは、チェック制約またはアプリケーション レベルのロジックで行うことができます。

これらのソリューションまたはその他のソリューションに関するさらなる意見をお待ちしております。

4

2 に答える 2

2

SiteId を単独で主キーにすることをお勧めします。DistrictId はおそらく外部キーである必要がありますか?

編集 - その場合、追加の PartnerDistrictId を外部キーに追加することをお勧めします。後で、あるサイトを別の地区の別のサイトと提携したいと思うかもしれません。しかし、個人的には、ここでは代理キーを支持します。そしてほとんどの場合;)

于 2009-08-26T14:44:44.503 に答える
0

命名コメント... Site_Id 自体は一意ではありませんか? Site_id という名前は iut であることを暗示しています。District_Id との組み合わせでのみ一意である場合は、名前が間違っている可能性があります.site_Sequence、District_site_No、またはその他の明確なものであれば、より明確になる可能性があります。

あなたのドメインモデルを理解していれば、地区内のすべてのサイトは同じルート親サイトから「派生」し、異なる地区のサイト間で重複することはありません...もしそうなら、DistrictIDをnull可能にすることで同じ機能を実現できます、ルート サイトに対してのみ入力します。次に、Site_Id を単一のフィールド PK にすることができ、ParentSiteId を単一のフィールド FK にすることができます。すべての「子」サイトは、ルートの親サイト レコードで指定された地区に「属します」。

于 2009-08-26T14:47:13.250 に答える