복합 키를 통한 외래 키로 대리 키

Question

비슷한 질문이있을 수 있지만 실현하기에 충분히 근접한 것을 발견하지 못했습니다. 이 스펙을 감안할 때

,

Site 
--------------------------- 
SiteID  int identity 
Name  varchar(50) 

Series 
--------------------- 
SiteID  int 
SeriesCode varchar(6) 
... 
--SeriesCode will be unique for every unique SiteID 

Episode 
---------------------- 
SiteID  int 
SeriesCode varchar(6) 
EpisodeCode varchar(10) 
... 

내 제안 된 설계/구현이 잘못

Site 
---------------------------- 
SiteID  int  identity 
Name  varchar(50) 


Series 
------------------------------------------- 
SeriesID int  identity, surrogate key 
SiteID  int   natural key 
SeriesCode varchar(6) natural key 
UNIQUE(SiteID, SeriesCode) 
... 

Episode 
------------------------------------------- 
EpisodeID int  identity, surrogate key 
SeriesID int  foreign key 
EpisodeCode varchar(6) natural key 
... 

아무것도 무엇입니까? 여기에 외계 * 키로 SeriesID 대리를 사용하는 것이 괜찮습니까? 발생할 수있는 명백한 문제가 누락 된 것인지 확실하지 않습니다. 또는 복합 자연 키 (SiteID + SeriesCode/SiteID + EpisodeCode)를 사용하는 것이 더 좋을까요? 본질적으로 그것은 시리즈 테이블에서 에피소드 테이블을 분리 할 것이고 그것은 나를 위해 앉아 있지 않습니다.

값을 더하면이 테이블을 채울 원시 입력 데이터에서 SeriesCode가 'ABCD-1'처럼 보이고 EpisodeCode가 'ABCD-1NMO9'와 같아서 변경 될 수 있습니다.

* : 이전에 높은 업에 의해 결정되었습니다 때문에 "가상"외래 키, 우리는 모두가 잘 보이는, 실제 외래 키

Answer 1

Yes (예)를 사용할 수 없습니다. Episode에서 다른 네 번째 자식 테이블을 사용하지 않는 한 EpisodeId가 필요하지 않을 것입니다. EpisodeCode는 Episode에서 행을 식별하고 찾을 수있는 단일 속성 자연 키입니다. 물론 거기에 그대로두면 아무런 해가되지 않습니다. 그러나 일반적으로 하위 테이블에있는 FK의 타겟 역할을하는 대용 키를 추가하고 모든 테이블에 중복 키 데이터를 식별하고 제어하는 ​​서술 키를 추가하려고합니다 ... 그래서 테이블에 참조하는 FK가있는 다른 테이블이 없다면 (그리고 절대로 없을 것입니다.) 때때로 그 테이블에 대리 키를 포함시켜야 할 필요가 없습니다.

Answer 2

"가상"외래 키 란 무엇입니까? 상위 - 업은 외래 키 제약 조건을 사용하지 않기로 결정 했습니까? 이 경우 외래 키를 전혀 사용하지 않습니다. 넌 그냥하는 척하는구나.

에피소드가 엔티티에 가장 적합한 선택입니까? 정말 쇼 또는 팟 캐스트를 의미하지 않습니까? 그리고 항상 지금 바로 시리즈의 일부가 되나요? 그렇다면 앞으로 변화 할 것인가? 에피소드는 결국 시리즈 외부에있는 쇼를 포함하기 위해 남용 될까요? 이 경우, 시리즈를 통해 사이트에 에피소드를 묶는 것은 다시 당신을 붙잡을지도 모릅니다.

당신이 과자로 생각하면 아마도 그것을 바꿀 수 없을 것입니다. 만약 내가 당신이라면 가능한 한 자연스러운 키를 사용하여 더 안전하게 느낄 것입니다. 외래 키 제약 조건이 없으면 나쁜 데이터를 쉽게 인식 할 수 있습니다. 나중에 자연 키를 사용하면 쉽게 SeriesCode = 'EMPTY'라는 속임수를 사용하면 쉽게 해결할 수 있습니다.

Answer 3

나의 제안 :

를 사용하여 기본 키로 자연/비즈니스 할 때마다 다음과 같은 세 경우를 제외하고 가능한 :

이

1. 자연/비즈니스 키
를 삽입하는 순간에 알 수없는입니다
2. 자연/비즈니스 키가 이 아닙니다. (고유하지 않으므로 자주 변경 될 수 있습니다)
3. 자연/비즈니스 키 더 세 이상의 열의 복합이고 테이블은 자식 테이블 상황 1에서

2 대용 키가를 requiered 이다있을 것이다.

상황 3에서 대리 키는 크게 을 권장합니다.