여러 관계에 대해 하나의 테이블이 없어야하는 이유는 무엇입니까?

내 데이터베이스에 상점, 직원 및 판매와 같은 여러 관계가 있고 간단한 이진 관계로 쌍을 연결하려고한다고 가정합니다. 개인적으로 외래 키로 구성된 자연 키를 사용하여 Employee_Store 및 Employee_Sale이라는 테이블을 만듭니다.

이제 동료가 여러 관계에 대해 하나의 테이블을 작성해야한다고 주장합니다. 위의 예에서 EmployeeLinks라는 테이블이있을 수 있습니다.

EmployeeLinks(
    IdLink int PK, 
    IdEmployee int FK null,
    IdStore int FK null,
    IdSale int FK null,
    LinkType int not null
)

이것이 좋은 생각이 아닌 이유를 알려주세요. 나는 내 자신의 주장을 가지고 있지만 나는 그것들을 비공개로 유지하고 편견없는 의견을 듣고 싶습니다.

편집하다:

처음에는 위 표에 기본 키 (!)가 없습니다. 외래 키는 null을 허용하기 때문에 대리 키가 유일한 옵션입니다.

동료가이 링크 테이블의 기본 키로 무엇을 제안합니까?
기본 키 열은 물론 NULL 일 수 없습니다. 위의 테이블은 널 입력 가능합니다.

(a IDENTITY 열의 기본 키 없음), 따라서,이 실패 위의 예에서 모든 천연 행 식별자 (a PK가 무엇 인)가 아닌 임의의 모델링 프로세스. 어떤 모델 (ERD, ORM, IDEF1X 등)없이 테이블을 만드는 것에 대해 생각조차하지 마십시오.

또한 3 방향 링크가 없도록 CHECK 제약 조건이 필요합니다.

마지막으로, 네 번째와 다섯 번째 일반 양식 영역으로 벗어나고 있지만 잘못된 이유가 있습니다.

인터넷에서 어떤 예도 찾을 수 없습니다.

내가 생각할 수있는 첫 번째 실질적인 이유는 성능입니다.

"전통적인"모델에서는 Idemployee, Idstore필드 또는 그 밖의 필드 에 대해 고유 한 인덱스를 가질 수 있으며 조회 성능이 뛰어납니다. 인서트의 유지 관리도 쉽습니다. 고유 한 인덱스를 사용하면 조인을 더 자주 병합 할 수 있으므로 JOIN엄청나게 빠른 속도 를 낼 수 있습니다 .

예제 모델에서 적절한 성능을 얻으려면 최소한 테이블의 모든 FK 필드에 단일 필드 인덱스가 있어야합니다.

• 직원 / 상점
• 직원 / 판매

링크 유형이 무엇인지 잘 모르겠지만 참조하는 경우 색인화해야합니다.

이러한 인덱스는 필드가 채워 졌는지 여부에 관계없이 테이블의 모든 행에 대해 유지 보수되어야합니다. 필터를 추가 할 수 있지만 조합이 너무 많으면 까다로울 수 있습니다.

또한 논리가 복잡해집니다. employeeid를 조회하고 빈 상점 값을 가진 행을 찾은 후 업데이트해야합니다. 또는 모든 새 링크에 대해 새 행을 삽입하면 필드를 통합하려는 목적에 위배됩니다.

기본적으로 더 많은 디스크 공간을 사용하고 더 많은 인덱스를 유지 관리하며 본질적으로 아무 이유없이 논리를 복잡하게 만듭니다. 유일한 "이점"은 처리해야 할 테이블 수가 적다는 것입니다.

여러 관계를 하나의 테이블에 배치하면 해당 관계에 동일한 특성이 있거나 여러 관계에 대한 데이터를 집계하려는 경우 유용 할 수 있습니다.

런타임에 사용자가 관계 유형을 정의한 경우 필요합니다. 그러나 이것은 거의 사실이 아닙니다.

귀하의 예에서 관계는 속성을 공유하지 않으며 관계는 두 개의 서로 다른 테이블을 나타냅니다. 이로 인해 제약 조건을 적용하기가 어려우며 디자인도 덜 직관적입니다.

문자 그대로 테이블을 만드는 데 비용이 드는 경우에만 해당 디자인을 선택했습니다.