2011-05-15 1 views
0

여기 내가 지금있는 곳입니다. 태스크, 프로젝트, 기회 및 task_xref라는 네 개의 테이블이 있습니다. 프로젝트 및 기회 테이블 각각에는 작업과 일대 다 관계가 있습니다. task_xref에 이러한 관계를 저장하려고합니다.2 개 이상의 테이블을 가진 다 대다 관계를 처리하는 방법은 무엇입니까?

task 
---- 
id(pk) 
name 

project 
------- 
id(pk) 
name 
... 

opportunity 
----------- 
id(pk) 
name 
... 

task_xref 
--------- 
task_id(task id) 
fkey(other table id) 

프로젝트와 기회의 키가 같은 (GUID) 수 없음을 가정 있도록 기회 등 프로젝트에 대한 작업을 페치 할 수 없습니다 스키마 (간체) 각 테이블에 대해 다음과 같이 보입니다 . 이는 표면에서 잘 작동하며, 하나의 xref 테이블은 작업과 프로젝트, 기회 (또는 앞으로 작업 관계가 필요할 수있는 다른 테이블) 간의 관계를 유지합니다.

내 현재 딜레마는 양방향입니다. 개별 프로젝트 또는 기회에 대한 모든 작업을 얻으려고한다면 아무런 문제가되지 않습니다. 작업을 취소하고 관련 프로젝트 또는 기회의 이름을 알고 싶지 않으면 할 수 없습니다. 관련된 fkey가 프로젝트인지 또는 기회인지를 알 수있는 방법이 없습니다. 미래에는 작업 관계가있는 다른 테이블이있을 것입니다. 나는 2 개의 테이블을 가지고 있지만 미래에는 더 많은 테이블이있을 수 있습니다. 1) 각 쌍에 대해 별도의 외부 참조 테이블 (예를 들어 task_project_xref, task_opportunity_xref ...) 단점 : 여기

은 지금까지 생각했던 해결할 수 있습니다 나는 각 외부 참조 테이블이 찾고에 대한 쿼리를 실행해야 작업

2) task_xref에있는 제 3 열의 관계는 부모 테이블에 단점을 가리 키도록이가 나에게 kludge

3) (식별 가능한 방식으로 프로젝트, 기회의 기본 키를 저장하는 것 같아 예 : proj1, proj2, proj3, opp1, opp2, opp3) 그래서 어떤 테이블이 fkey를보고 어떤 테이블과 관련이 있는지 알 수 있습니다. 죄수 팀 : 프로젝트와 기회에서 기본 키를 만드는 것처럼 느껴진다. 단일 레코드에 대한 식별자가 아닌 의미를 더 많이 묻는다. (어쩌면 내가 과도하게 생각하고있다.)

내가 바라 보는 다른 해결책이 있습니까? 어떤 솔루션이 다른 솔루션보다 좋고/더?

가능하면 가능한 한 조인을 제한하고 성능을 좋게 유지하려고합니다. 또한 코드를 사용하여 데이터를 결합하는 것이 사물을 단순화하는 데 도움이된다면 반대하지 않습니다.

저는 PHP와 MySQL을 사용하고 있습니다 (MyISAM 테이블은 현재 사용하고 있지만 이유가있을 경우 INNODB를 사용합니다).

답변

0

나는 다른 개념을 위해 별도의 외부 참조 테이블을 갖는 것을 선호합니다. 이렇게하면 개념에서 작업에 이르는 관계가 유지 관리가 쉬우 며 다른 개념과 작업의 관계에서 격리됩니다.

나는 당신의 디자인에있는 표는 작업을 가질 수하고 난 그냥 객체의 종류 표시하기 위해 여분의 열이있을 것이다 경우 모든 관련 개념에 대해 하나의 외부 참조가의 부모 어쩌면 부탁을 거라고 과제들.

+0

이것은 사용자가 응용 프로그램과 상호 작용하는 방법을 생각한 후에는 아마도 내 특정 상황에 맞는 '올바른'솔루션 인 것처럼 보였습니다. jodes가 지적했듯이 어쨌든 2 개의 쿼리가 필요합니다. 이 방법은 각 개념이 자체 데이터를 관리하도록 내 패턴을 유지하고 있습니다. – Jon

0

task_xref에 별도의 project_id 및 opportunity_id 필드가 있으면 SQL 조인이 더 어둡습니다. 그것은 쿼리가 간단하기 때문에 좋은 방법입니다. 또한 단순히 외래 키 중 어떤 것이 null이 아닌지 확인하여 어떤 유형의 태스크인지 간단하게 알 수 있습니다. 그것은 또한 효율적입니다. 프로젝트에 합류 할 때 두 가지 쿼리가 필요합니다. 프로젝트와 기회가 틀린 구조이므로 의심 할 여지없이 결과가 union이 될 수 없습니다.

관련 문제