Composite-Taste auf einer Selbst Referenzierung Tabelle

Question

Wir haben einen zusammengesetzten Primärschlüssel für die Site-Tabelle unten definiert. Funktionell, tut dies genau so, wie wir es möchten. Jede Seite sollte eine übergeordnete Stelle des selben Bezirk haben. auf diese Weise die Tabelle definieren, können speziell für.

    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 konkrete Frage ist in Bezug auf die sich selbst verweis FK auf einem Verbund PK definiert. Ich habe ein paar Meinungen zu diesem Design gehört und sie neigen dazu, in Konflikt werden. Manche mögen es vor allem, weil es funktioniert, wie es sollte in einem allgemeinen Verständnis für zusammengesetzte Schlüssel. Andere bestehen darauf, dass es theoretisch falsch ist und dass es auch ein [partner_district_id] Feld, das in der FK statt [district_id] enthalten ist. Dieser Entwurf würde Validierung erfordern zu erzwingen, dass die [district_id] = [partner_district_id], die entweder mit einer Check-Einschränkung oder Anwendungsebene Logik getan werden könnte.

Weitere Stellungnahmen zu diesen Lösungen oder jede andere würde geschätzt.

Answer 1

würde ich vorschlagen SITEID auf es selbst ist der Primärschlüssel sein. DistrictId soll wohl ein Fremdschlüssel sein?

EDIT - in diesem Fall würde ich vorschlagen, die zusätzliche PartnerDistrictId auf den Fremdschlüssel hinzuzufügen; man weiß ja nie, können Sie später wollen Partner eine Website mit einem anderen in einem anderen Bezirk. Aber persönlich würde ich hier für einen Ersatzschlüssel sein. Und in den meisten Fällen;)

Answer 2

Namensgebung Kommentar ... Ist das SITE_ID selbst nicht einzigartig? Ursache der Name impliziert, dass SITE_ID iut ist. Wenn es nur einzigartig in Kombination mit District_Id ist, dann ist es vielleicht falsch benannt ... könnte es klarer, wenn es site_Sequence ist, oder District_site_No, oder etwas anderes klarer.

Wenn ich Ihr Domain-Modell verstehe, dann alle Seiten in einem Stadtteil ‚derive‘ aus dem gleichen Wurzel übergeordneten Standort, und es kann keine Überschneidungen zwischen sitres in verschiedenen Bezirken sein ... wenn ja, dann die gleiche Funktionalität achioeved werden könnte durch Herstellung DistrictID nullable, und es nur für die root-Sites bevölkern. Dann könnte die SITE_ID ein einzelnes Feld PK sein, und ParentSiteId könnte ein einziges Feld FK sein. Alle ‚Kind‘ Websites würden ‚gehören‘ in den Kreis ihrer Stammübergeordneten Standort Datensatz bezeichnet.