Zusammengesetzter Schlüssel für eine selbst referenzierende Tabelle

Question

Wir haben einen zusammengesetzten Primärschlüssel für die unten definierte Standorttabelle. Funktional funktioniert das genau so, wie wir es gerne hätten. Jeder Standort sollte eine übergeordnete Website desselben Bezirks haben. Die Definition der Tabelle auf diese Weise ermöglicht dies speziell.

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]) 

Meine spezifische Frage bezieht sich auf den selbst-referenzierenden FK definiert auf einer zusammengesetzten PK. Ich habe ein paar Meinungen zu diesem bestimmten Design gehört und sie neigen dazu, widersprüchlich zu sein. Manche mögen es besonders, weil es innerhalb eines allgemeinen Verständnisses von zusammengesetzten Schlüsseln so funktioniert, wie es sollte. Andere bestehen darauf, dass es theoretisch falsch ist und dass es auch ein Feld [partner_district_id] geben sollte, das im FK statt in [district_id] enthalten ist. Dieser Entwurf würde eine Validierung erfordern, um das [district_id] = [partner_district_id] zu erzwingen, was entweder mit einer Prüfbeschränkung oder einer Logik auf Anwendungsebene erfolgen könnte.

Weitere Meinungen zu diesen oder anderen Lösungen sind willkommen.

Answer 1

Ich würde vorschlagen, SiteId selbst ist der Primärschlüssel. DistrictId sollte wahrscheinlich ein Fremdschlüssel sein?

BEARBEITEN - in diesem Fall würde ich vorschlagen, die zusätzliche PartnerDistrictId dem Fremdschlüssel hinzuzufügen; Sie können nie wissen, dass Sie später eine Seite mit einer anderen in einem anderen Bezirk zusammenarbeiten möchten. Aber persönlich wäre ich hier für einen Ersatzschlüssel. Und in den meisten Fällen;)

Answer 2

Benennung Kommentar ... Ist die Site_Id nicht eindeutig? Weil der Name Site_id andeutet, dass es iut ist. Wenn es nur in Kombination mit District_Id eindeutig ist, dann wird es vielleicht falsch benannt ... es könnte klarer sein, wenn es sich um site_Sequence oder District_site_No oder etwas anderes handelt.

Wenn ich Ihr Domain-Modell verstehe, dann leiten sich alle Sites in einem Distrikt von der gleichen Root-Parent-Site ab, und es kann keine Überlappung zwischen Sitres in verschiedenen Distrikten geben ... wenn ja, könnte die gleiche Funktionalität achioeved sein indem Sie die NULL-Kennzeichnung für DistrictID festlegen und sie nur für die Stammwebsites auffüllen. Dann könnte die Site_Id ein einzelnes Feld PK sein, und ParentSiteId könnte ein einzelnes Feld FK sein. Alle "Kinder" -Sites würden zu dem Bezirk gehören, der in ihrem Stammeltern-Site-Datensatz angegeben ist.