Clave compuesta en un Referencing Tabla Auto

Question

Tenemos una clave principal compuesta de la tabla sitio se define a continuación. Funcionalmente, esto hace exactamente como nos gustaría que lo haga. Cada sitio debe tener un sitio primario del mismo distrito. La definición de la tabla de esta manera permite específicamente para eso.

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

Mi pregunta concreta es sobre el FK referencia a sí misma definida en un PK compuesto. He escuchado algunas opiniones sobre este diseño en particular y que tienden a ser contradictorios. A algunos les gusta sobre todo porque funciona como es debido dentro de una comprensión general de las claves compuestas. Otros insisten en que en teoría es incorrecta y que también debe ser un campo [partner_district_id] que se incluye en el FK en lugar de [district_id]. Este diseño requeriría la validación para hacer cumplir que el [district_id] = [partner_district_id], lo que podría hacerse ya sea con una restricción de comprobación o lógica de nivel de aplicación.

Otros comentarios sobre estas soluciones o cualesquiera otros serían apreciados.

Answer 1

Me gustaría sugerir SiteID por sí mismo sea la clave principal. DistrictId probablemente debería ser una clave externa?

EDITAR - en ese caso, me gustaría sugerir la adición de la PartnerDistrictId adicional a la clave externa; nunca se sabe, puede que más adelante desea asociarse un sitio con otro en un distrito diferente. Pero, personalmente, estaría a favor de una clave sustituta aquí. Y en la mayoría de los casos;)

Answer 2

nombrando comentario ... ¿Está el site_id por sí mismo no es único? Hacer que el nombre de site_id implica que es IUT. Si sólo es único en combinación con District_Id, entonces es quizá mal llamada ... puede ser que sea más claro si se tratara de site_Sequence o District_site_No, o algo más clara.

Si entiendo su modelo de dominio, entonces todos los sitios en un distrito 'Derivar' desde el mismo sitio primario de la raíz, y no puede haber una superposición entre sitres en diferentes distritos ... si es así, la misma funcionalidad podría achioeved por haciendo DistrictID anulable, y sólo poblarlo de los sitios de raíz. A continuación, el site_id podría ser un único campo de PK, y ParentSiteId podría ser una sola FK campo. Todos los sitios pediátricas serían 'pertenecer' a la zona designada en su registro raíz de los padres del sitio.