계층 구조/하위 범주가있는 SQL 테이블 설계

Question

다음과 같은 테이블이 있습니다.

ID | 키워드 | 카테고리 | 하위 카테고리 | 하위 하위 카테고리 | 하위 하위 범주

하나의 키워드가 하나의 카테고리, 하위 카테고리에만 속할 수있는 경우 두 테이블 (상위 테이블이있는 키워드 테이블 및 카테고리 테이블)로 분할해야합니까? 기타 반복이 없다는 것을 의미합니다. 아직도 그걸 갈라 놓을 필요가 있니?

Answer 1

1-1 매핑을 나타내는 테이블이 하나만 있으면됩니다. 1-many 또는 many-many 매핑을 표현하려면 여러 테이블을 사용해야합니다.

키워드가 하나의 카테고리/하위 카테고리/하위 카테고리에만 대응할 수있는 경우 현재 레이아웃이 좋을 것입니다.

주의 사항 : 키워드를 기준으로 검색하려는 경우 표를 분리 할 때 성능이 향상 될 수 있습니다. 정수 검색을 수행하는 것이 훨씬 빠릅니다.

다른 테이블에 키워드 값을 저장하는 것에 대한 설명은 다른 테이블에 국가 이름 (대부분 정적 인)을 저장하는 this discussion에 해당합니다. 다른 테이블을 사용할 때의 주요 이점은 (말한) 언어 독립성, 빠른 검색 및 나중에 쉽게 업데이트 할 수 있다는 것입니다.

Answer 2

이렇게 두 테이블을 사용합니다.

Categories 
------------------- 
PK,FK1 | CategoryID 
     | Keyword 
     | Category 

    SubCategories 
-------------------- 
PK,FK1 | CategoryID 
PK,FK1 | SubCategoryID 

Answer 3

이름을 바꾸거나 나중에 범주를 재 배열 할 것으로 예상 경우가 그것을 분할하는 의미가 있습니다 그대로 당신이 그것을 떠날 경우, 해당 이름 변경을해야 할 것

• /그 (((하위) 하위) 하위) 카테고리를 포함하는이 테이블의 모든 행에 대해 단계 (카테고리/하위 카테고리/하위 카테고리/하위 카테고리/하위 카테고리 필드 변경)를 재구성하십시오. 더 복잡한 쿼리가 발생하고이 키워드 테이블에 매우 많은 행이 있으면 성능 문제 일 수 있습니다 (데이터베이스가 수행하는 데 다소 시간이 걸릴 수 있음). 반면에, 쿼리 (읽기)는 가능한 한 빨리됩니다.
• 위로 나누면 updated (((sub) sub) category는 적은 행으로 만 수행되지만 두 개 (또는 그 이상)의 테이블로 작업해야하므로 쿼리 (read)가 더 오래 걸립니다 .

모두의 단점과 장점의 무게를 측정 한 후 decision.m가

Answer 4

왜뿐만 아니라 PK에 ParentID 열 및 FK를 추가 할?

Answer 5

나는 각 외래 키가 범주 테이블에서 오는 두 테이블에서 할 것

:

category_id category parent_category_id 
1    Food  null 
2    meat  1 
3    organic  1 
4    fruit  3 

그 데이터 : 같을 것이다 Categories 테이블에

Keywords 
id (PK) 
keyword 
category_id (FK) 

Categories 
category_id (PK) 
category 
parent_category_id (FK) 

데이터를 키워드 표는 다음과 같을 것입니다 :

id  keyword category_id 
1  grapes  4 
2  chicken 2