db 설계 도움좀 부탁합니다 ㅠㅠ 0 3 162

by 캐뉴비 [2021.09.08 13:52:45]


테이블 A   테이블 B   테이블 C
PK A   PK A   PK A
      PK B   PK B
            PK C

기존 위와같은 테이블로 설계 되어있는 것을

 

테이블 A   테이블 B   테이블 C
PK A   FK A   FK B
      PK B   PK C

이와 같이 변경하는게 맞을까요?

 

가령 A값과 B값을 가지고 있는 상태에서 테이블C 를 조회할때 Join 구문이 필요하게 되는데

C의 테이블이 250만건이상으로 크기가 크고

이런 형식의 1:n 테이블 수가 좀 많이 존재 합니다

 

아래와 같이 구조를 변경하는게 맞는거 같으면서도 아닌거 같은데 

가르침 부탁드립니다 ㅠㅠ

by 우주민 [2021.09.08 14:10:55]

데이터의 성격을 떠나서 구조적으로는 복합PK 를 PK와 FK 로 나누는거 부터가 의미하는 바가 달라지네요.

PK1 PK2 의 데이터를

A, 1

A, 2

B, 1

B, 2

의 식으로 처리가 된다면

 

PK, FK 형태로 변경될때

A , 1 OR 2

B, 1 OR 2

형태로 PK 에 종속적인 FK 1개 값만이 가능해지니까

데이터 상으로도 다른 데이터 형태가 될듯 한데요.


by 마농 [2021.09.08 14:51:19]

FK 표시 방식
- FK 표사를 PK 를 대체하는 방식으로 하면 안되고 별도란으로 표시해야 합니다.
- 첫번째 설계에서도 A 는 FK 이면서 동시에 PK 인거겠죠.
테이블 설계
- 첫번째 방식은 FK 로 가져온 인자가 PK 에 포함되는 구조이고(복합PK)
- 두번째 방식은 FK 로 가져온 인자가 PK 에 포함되지 안는 구조네요(단일PK)
각각 장단점이 있을 것입니다.
식별자의 명확성
- 첫번째는 키가 명확하다는 것이죠. 실질식별자 형태일 듯 합니다.
- 두번째는 인조식별자 형태가 될 것이구요.
조인의 편리성
- 첫번째는 조인 조건이 더 많이 들어가야 하겠네요.
조인의 필요성
- C 를 통해 A 를 알아야 하는 경우
- 첫번째는 C 만 가지고도 조인 없이 구할 수 있지만
- 두번째는 C 만 가지고는 안되고 조인을 반드시 해야만 합니다.


by 캐뉴비 [2021.09.08 16:45:55]

저의 상황이면 실질식별자 쪽으로 유지하는게 더 이득이겠네요 답변 감사합니다

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입