2

동일한 아이디어에 대해 두 가지 접근 방법을 생각해 봤지만 서로를 사용하여 분명한 함정을 피하려고합니다. 하나의 행이 다른 테이블 (tbl_category, tbl_site, tbl_team)과 많은 관계를 가질 수있는 테이블 (tbl_post)이 있습니다. 나는 이것들을 결합시키는 관계 테이블을 가지고 있지만 어떤 구조가 조건부인지 직접적인지를 모른다. 다행히도 다음과 같이 설명 할 것입니다 ...SQL 조건부 관계

tbl_post (simple post, can be associated with many categories, teams and sites) 
* id 
* title 
* content 

tbl_category 
* id 
* title 
* other category only columns 

tbl_team 
* id 
* title 
* other team only columns 

tbl_site 
* id 
* title 
* other site only columns 

---------------------------------------------------------- 
tbl_post_relationship 
* id (pk) 
* post_id (fk tbl_post) 
* related_id (fk, dependant on related_type to either tbl_category, tbl_site or tbl_team) 
* related_type (category, site or team) 

____________________________________ 
|id|post_id|related_id|related_type| 
|--|-------|----------|------------| 
| 1|  1|   6| category| 
| 2|  1|   4|  site| 
| 3|  1|   9| category| 
| 4|  1|   3|  team| 
------------------------------------ 

SELECT c.* 
FROM tbl_category c 
     JOIN tbl_relationship r ON 
      r.post_id = 1 
      AND r.related_type = 'category' 
      AND c.id = r.related_id 

------------- OR --------------- 

tbl_post_relationship 
* id (pk) 
* post_id (fk tbl_post) 
* category_id (fk tbl_category) 
* site_id (fk tbl_site) 
* team_id (fk tbl_team) 

________________________________________ 
|id|post_id|category_id|site_id|team_id| 
|--|-------|-----------|-------|-------| 
| 1|  1|   6| NULL| NULL| 
| 2|  1|  NULL|  4| NULL| 
| 3|  1|   9| NULL| NULL| 
| 4|  1|  NULL| NULL|  3| 
---------------------------------------- 

SELECT c.* 
FROM tbl_category c 
     JOIN tbl_relationship r ON 
      r.post_id = 1 
      AND r.category_id = c.id 

따라서 하나의 접근법으로 인해 많은 열 (더 많은 테이블이있을 수 있습니다)이 NULL로 끝납니다. 또는 하나의 간단한 테이블로 유지 관리하지만 모든 조인은 "유형"을 기반으로합니다. 나는 또한 관계 당 테이블을 가질 수 있다는 것을 알고 있지만 너무 많은 테이블과 같은 느낌이 들었습니다. 어떤 아이디어/생각?

답변

5

관계 당 하나의 테이블을 사용하는 것이 가장 좋습니다. 테이블의 양에 대해 걱정할 필요가 없습니다. 단일 관계 테이블의 단점은 여러 가지이며 매우 위험합니다.

1) 관련된 테이블이 행마다 다를 경우 데이터 무결성이 위험 할 수 있으므로 외래 키를 적용 할 수 없습니다 ... 조만간 고아 데이터가 있습니다.

2) 쿼리는 related_type을 사용하여 여러 위치에서 관계를 필터링해야하기 때문에 더 복잡합니다.

3) 쿼리 유지 관리는 2)와 같은 이유 때문에 더 많은 비용이 들며 여러 위치에서 related_type 상수를 명시 적으로 사용해야하기 때문에 변경하거나 추가해야 할 때 지옥이됩니다. .

난 정통 디자인을 사용하는 것이 좋습니다 ... 그냥 3 개의 서로 다른 관계 테이블을 가지고 : post_category, post_team, post_site.

+0

Thanks Frazz, 좋은 추론입니다. :) related_type 사용법을 정말 좋아하지는 않았지만 일부 오픈 소스 웹 응용 프로그램에서 사용되는 것을 보았습니다. 플러스 다른 결합 된 테이블은 모든 nulls와 바로 느끼지 않았다. 나는 여러 관계 테이블이 적절한 방법 일 것이라고 생각한다. –

+1

예, 관계 당 한 테이블 만주세요. 여기에 다중 도메인 테이블이 있습니다. 우리 테이블에는 관계없이 (응용 프로그램 계층의 유지 관계가 대부분 * 작동합니다 ...) 외래 키가 없습니다. 테이블의 일부에 단 하나의 도메인/유형을 넣었을 때 인덱스 열에 첫 번째 열로 형식 열을 넣으면 (더 이상 상수 값을 넘어서는) 더 심해집니다. –