2009-08-26 4 views
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] 대신 FK에 포함 된 [partner_district_id] 필드가 있어야한다고 주장하는 학자도 있습니다. 이 설계는 [district_id] = [partner_district_id]가 점검 제한 조건 또는 응용 프로그램 레벨 논리로 수행 될 수 있도록 유효성을 검사해야합니다.

이러한 솔루션이나 다른 의견에 대한 의견은 감사하겠습니다.

+0

명명 코멘트 ... Site_Id 자체가 고유하지 않습니까? 왜냐하면 Site_id라는 이름은 iut이라는 것을 의미하기 때문입니다. District_Id와 결합하여 유일한 경우 다음과 같이 잘못 명명되었을 수 있습니다. site_Sequence 또는 District_site_No 또는 기타 항목 인 경우 명확해질 수 있습니다 ... –

답변

2

사이트 아이디가 기본 키가 될 것을 제안합니다. DistrictId는 아마도 외래 키 여야합니까?

EDIT -이 경우 EDIT - 외래 키에 추가 PartnerDistrictId를 추가하는 것이 좋습니다. 다른 지역의 다른 사이트와 파트너가되고 싶을 수도 있습니다. 하지만 개인적으로 여기서 대리 키를 선호합니다. 그리고 대부분의 경우;)

+0

site_number (이전 site_id)는 실제로 자체적으로 고유하지 않습니다 . 이것은 자연 키 대 대리 키 토론과의 공통적 인 불일치이지만,이 토론이 필요하지 않은 한 거기에 가지 않기를 바랬습니다. 그것은 미끄러운 경사입니다. – LJM

0

명명 코멘트 ... Site_Id 자체가 고유하지 않습니까? 왜냐하면 Site_id라는 이름은 iut이라는 것을 의미하기 때문입니다. District_Id와 결합하여 유일하다면, 아마도 잘못된 이름이 붙었을 것입니다 ... site_Sequence, District_site_No 또는 다른 명확한 것이 더 명확 할 수 있습니다.

도메인 모델을 이해하면 지구에있는 모든 사이트가 동일한 루트 상위 사이트에서 '파생'되며 다른 지역의 Sitres간에 중복이 없어 질 수 있습니다. 그렇다면 동일한 기능이 적용될 수 있습니다 DistrictID를 null로 설정하고 루트 사이트에 대해서만 채 웁니다. 그런 다음 Site_Id는 단일 필드 PK 일 수 있고 ParentSiteId는 단일 Field FK 일 수 있습니다. 모든 '자녀'사이트는 루트 부모 사이트 기록에 지정된 지구에 속할 것입니다.

+0

죄송합니다. 문제를 일반화하려고 할 때 필드에 부여한 이름이 명확하지 않을 수 있습니다. 이름을 업데이트 했으므로 지금은 그다지 의미가 없을 수도 있습니다. – LJM