더 많은 조인 또는 더 많은 열이 있습니까?

Question

필자는 매우 기본적인 질문을 가지고 있는데, 이는 더 효율적인 디자인, 더 많은 조인을 포함하거나 더 큰 테이블에 열을 추가하는 것일까?

예를 들어

, 우리는 아래와 같은 친척을 저장 테이블이 있다면 :

Person | Father | Mother | Cousing | Etc. 
________________________________________________ 

가 직접 해당 테이블에 등 이름, 나이를 나열하는 것이 더 있을까를 ... 또는 더 나은 사람이하는 이름, 나이 등이있는 테이블, person_id 또는 뭔가로 연결되어 있습니까?

예를 들어이 두 가지 옵션 이상이 있기 때문에 약간 간단한 예일 수 있습니다. 그러나 설명을 위해 관계를 개인 테이블에 저장할 수 없다고 가정하십시오.

나는 위의 두 가지 선택 사항 중 후자를하고 있지만 사람 테이블이 충분히 커지거나 연결된 열이 충분할 때 성능에 문제가 생길지 궁금하다. 관계 테이블에.

Answer 1

각 개인의 세부 정보와 함께 관련 테이블을 구분하는 것이 훨씬 더 유연한 디자인입니다. 일반적으로 이는 데이터 소비를 줄입니다.

한 단계 더 나아가 사람들을위한 테이블 하나, relationship_types를위한 테이블 한 개, 관계를위한 테이블 한 개를 가질 수도 있습니다. 키, 라벨, 잠재적으로 설명을 할 것이다 나이, 이름 등

Relationship_types -

People

모든 개인 식별 정보를 가질 것이다. 이 표는 각 가능한 관계의 세부 사항을 자세히 설명하기위한 것입니다. 따라서 '부모'행, '아동'행, '형제'행 등이 있습니다.

Relationships 테이블에는 4 개의 필드가 있습니다. 하나는 관계에있는 각 사람의 키입니다. 하나는 relationship_type의 키이고 다른 하나는 자체 키입니다. person 열의 이름을 명확하게하여 어느 쪽이 관계의 어느 부분인지 분명히해야합니다 (예 : 이 인 사람을 나타내는 경우에만 A와 B가 '부모'관계를가집니다. 부모 대 은 부모를 가지고 있습니다.

Answer 2

당신이 데이터를 사용하려는 방법에 따라 더 나은 구조는

• 사람 (ID, 이름 등)에 대한 테이블

• 관계를 테이블 (person_a_id, person_b_id, relation_type 될 수있다 등) person_a_id person_b_id과 같이 보일 수 인 샘플 데이터를 ID 관련

사람

ID Name 
    1 Frank 
    2 Suzy 
    3 Emma 

관계

A B Relationship 
    1 2 Wife 
    2 1 Husband 
    1 3 Daughter 
    2 3 Daughter 
    3 1 Father 
    3 2 Mother 

Answer 3

ID는 '유연성을 높이고 데이터 중복을 줄이기 위해 더 "정규성"에 대한 이동합니다. 당신이 변화 코드없이 관계 (한 번 제거 4 사촌 어머니 쪽)을 지원할 수

PERSON: 
ID 
First Name 
Last Name 

Person_Relations 
PersonID 
RelationID 
TypeID 

Relation_Type 
TypeID 
Description 

이 방법.