Clé composite sur un tableau auto-référencé

Question

Nous avons une clé primaire composite pour la table de site définie ci-dessous. Fonctionnellement, cela fait exactement ce que nous voudrions. Chaque site devrait avoir un site parent du même district. Définir la table de cette manière permet spécifiquement cela.

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

Ma question spécifique concerne le FK auto-référencé défini sur un PK composite. J'ai entendu quelques opinions sur cette conception particulière et ils ont tendance à être contradictoires. Certains l'aiment particulièrement parce qu'il fonctionne comme il le devrait dans le cadre d'une compréhension générale des touches composites. D'autres insistent sur le fait qu'il est théoriquement incorrect et qu'il devrait aussi y avoir un champ [partner_district_id] qui est inclus dans le FK au lieu de [district_id]. Cette conception nécessiterait une validation pour appliquer le [district_id] = [partner_district_id], ce qui pourrait être fait avec une contrainte de vérification ou une logique au niveau de l'application.

D'autres opinions sur ces solutions ou d'autres seraient appréciées.

Answer 1

Je suggérerais que SiteId soit la clé primaire. DistrictId devrait probablement être une clé étrangère?

EDIT - dans ce cas, je suggère d'ajouter le PartnerDistrictId supplémentaire à la clé étrangère; vous ne savez jamais, vous pouvez plus tard vouloir associer un site avec un autre dans un district différent. Mais personnellement, je serais en faveur d'une clé de substitution ici. Et dans la plupart des cas;)

Answer 2

nommer un commentaire ... L'ID de site n'est-il pas unique en soi? Parce que le nom Site_id implique que iut est. Si elle n'est unique qu'en combinaison avec District_Id, elle est peut-être mal nommée ... il pourrait être plus clair si c'était site_Sequence, ou District_site_No, ou quelque chose d'autre plus clair. Si je comprends votre modèle de domaine, alors tous les sites d'un district "dérivent" du même site parent, et il ne peut y avoir de chevauchement entre les sites dans différents districts ... si c'est le cas, la même fonctionnalité pourrait être obtenue En rendant DistrictID nullable, et seulement le remplir pour les sites racine. Alors le Site_Id pourrait être un seul champ PK, et ParentSiteId pourrait être un seul Field FK. Tous les sites «enfants» appartiendraient au district désigné dans leur enregistrement de site parent parent.