일치하는 클라이언트와 서비스에 대한 모델을 고려하십시오. 고객은 다양한 시간에 서비스 제공자와 서비스 소비자가 될 수 있습니다. 고객은 개인 또는 그룹 (회사) 일 수 있으며 후자는 여러 연락처가 있습니다. 주소록에는 여러 주소, 전화, 전자 메일이있을 수 있습니다. 이러한 관계 중 일부는 일대일 (예 : 제공 업체에 대한 서비스)이지만 대다수는 일대 다 또는 다 대다 (여러 회사의 연락처는 동일한 주소를 가짐)입니다. 여러 연관 테이블이 일반적으로 존재하는 것이이 모델, 예를 들어, client_contact, contract_addr, contact_phone, CONTACT_EMAIL, SERVICE_PROVIDER, service_consumer에서 "마스터"연관 테이블?
등주어진 서비스의 소비자를위한 연락처 정보에 대한 간단한 쿼리를 실행 말. 데이터가 들어있는 6 개의 엔티티 테이블 외에도 조인은 5 개의 연관 테이블을 참조합니다. 물론 이런 종류의 질의에 대해 특히 흥미로운 것은 없습니다. 우리는 매일 그렇게합니다.
그러나 나에게도 일어났습니다. 왜 모든 연관성을 지닌 단일 "마스터"연관 테이블이 없습니까? 이 마스터 테이블에는 두 개의 PK 외에도 "연관 유형"이 있고 모든 PK는 동일한 유형 (int, GUID 등)이어야합니다.
한편으로는 각 조인이 형식과 PK를 지정해야하므로 쿼리가 더 복잡해집니다. 반면에 모든 조인은 동일한 테이블에 액세스하고 적절한 인덱스 및 캐싱 성능으로 극적으로 향상 될 수 있습니다.
이 방법을 설명하는 패턴 (또는 패턴 방지)이있을 수 있지만 온라인에서 아무 것도 발견하지 못했다고 가정했습니다. 아무도 그것을 시도 했습니까? 그렇다면 확장 성이 있습니까?
제공 할 수있는 참조는 만족 스러울 것입니다.
마음에 드네요. 위선적 인 생각이 들어요. 이건 정말 나쁜 생각인데 정확한 (기술적 인) 이유를 정확하게 지적 할 수는 없어요. 여러분은 여러분이이 설정에 대한 잠금 문제에 매우 취약하다는 것을 주장 할 수도 있습니다. 그리고 필요한 경우 다 대 다 관계에 메타 데이터를 실제로 추가 할 수 없습니다. 또한 적절한 RDBMS가 사용자가 언급 한 상황을 처리하기 위해 최적화되었다고 가정합니다. –
그것은 내 생각이었습니다. 그래서 나는 적어도 CRUD가있는 곳에서는 정말 나쁜 생각으로 문서화되지 않았 음을 알면 놀랐습니다. 나는 낮은 TX 볼륨으로 의심스럽고 쿼리가 낮은 격리 상태에서 살아갈 수 있다고 믿을 수 있습니다. 단일 "마스터"테이블이 더 나은 최적화를 가져올 수 있다고 가정했지만 특정 RDBMS에 따라 달라질 수 있습니다. 계획을 비교하는 것은 ("마스터"대 규칙적 assoc) 유익한 것입니다. – djhill8262
형식이 키 또는 인덱스의 상위 부분이 될 것이라고 생각하고 있으므로 조인은 다음과 같습니다. Type = 'Type1'AND PK1 = PK2? 이 경우 성능이 실제로 더 좋을까요? –