복합키 VS 대표 ID PK

데이터를 식별하기 위해 키(PK)를 이용합니다. 복합키는 데이터를 대표하는 키가 여러 개의 컬럼으로 구성된 것을 의미합니다.

데이터를 더욱 효과적으로 찾기 위해 키에는 기본적으로 PK 인덱스가 생성됩니다. 인덱스는 키의 위치를 정리해둔 것으로 키가 등록/삭제 되었을 때 키의 위치 기록을 하는 수고를 감수하고, 조회할 때의 성능 이점을 얻기 위해 사용됩니다. 이때 PK를 대상으로 인덱스가 자동으로 생성되는데, 이것을 PK 인덱스라고 합니다.

복합키의 경우 조회 조건의 컬럼 조합에 따라 쿼리 성능이 많이 달라지게 됩니다. 복합키 내에서는 일반적으로 카디널리티가 낮은 순에서 높은 순으로 인덱스를 구성하면, 사용하는 쿼리에서도 무난하게 사용이 가능합니다. 하지만 상황에 따라 인덱스의 컬럼 순서를 변경하거나 추가 인덱스를 구성해야할 수도 있습니다.
카디널리티와 복합키 PK 순서에 대해 자세히 알고 싶으시면 아래 글을 추천합니다.
카디널리티와 복합키 순서 그리고 PK Index

Spring JPA 복합키 순서와 PK Index

---

대표 ID PK를 사용하는 게 유용할 때

예를 들어 도서 정보를 관리하는 테이블이 있을 때, 복합키는 이름, 저자, 출판사이라고 가정하겠습니다.

위와 같이 대표PK 없이 복합키로만 테이블을 구성하는 경우, 해당 도서의 정보를 변경하거나 조회할 때 마다 세 가지 정보를 모두 알아야합니다. (그리고 테이블이 도서 정보가 아니라, 개인정보처럼 민감한 정보가 들어있다면 PK 컬럼이 노출되어서는 안될 수도 있습니다. 그러면 이 정보를 관리하는 자는 이런 도메인 PK 대신 이 ROW를 찾아낼 방법이 필요하겠지요.)

대표 PK를 사용하는 게 유리할 때

• 클라이언트 쪽에서 복합키의 정보를 모두 알지 않아도 간편하게 리소스 관리가 가능함 (ex: 책ID, 사용자ID)
• 데이터를 식별할 수 있는 컬럼의 조합이 유니크하지 않을 때 (ex: 이름+저자+출판사로는 책 식별 불가할 수 있음. 동일한 명칭의 개정판이 나오기 때문)
• 식별가능한 복합키의 값이 변경 가능할 때 (책 이름, 저자의 필명, 출판사는 언제든 변경 가능함)

주의할 점

• 인덱스가 기본적으로 하나 추가됨 (대표PK + 복합컬럼 인덱스)

---

복합키를 구성하는 경우

• 특정 데이터를 식별하는 게 의미가 없는 도메인 (ex: 걸음기록과 같은 통계성 데이터)
• 사용 예) 걸음기록 저장
• 조회 : 사용자별 최근 일주일간 평균 걸음 수

이름을 PK로 두긴 했지만, user_id를 의미합니다ㅎㅎ
이런 통계성, 기록성 데이터는 ID가 존재하더라도 그 ID를 이용해 데이터를 조작하거나 하지 않습니다.
그래서 이런 경우에는 ID key를 추가하는 대신 사용자+기록일시 기준으로 복합키를 구성합니다.
조회 시에도 사용자+기록일시에 대한 조회기간으로 필터링되니까 PK 인덱스도 아주 잘 타겠지요!
이 테이블 예제는 위에서 링크한 카디널리티와 복합키 순서 그리고 PK Index에서도 다뤘던 예제인데, 카디널리티 측면에서도 생각해봐도 재미있습니다.

---

데이터 특성에 따라, 어떻게 조회하고 데이터를 조작할 것인지에 따라 같은 복합키 테이블이라도 대표 ID 키를 구성할 때도 있고, 복합키로 구성할 때도 있습니다.
이 구분이 모호할 때에는 안전하다고 판단되는 대표키를 추가하는 방식을 선택하고, 추가로 복합키였던 컬럼들에 대한 인덱스를 구성하는 편입니다.
대표키를 생성한다고 하더라도 기존 컬럼들이 유니크한 값이 아니게 되지는 않으니, 데이터 정합성을 위해 유니크 인덱스를 걸어줘야합니다 :)

대표 ID PK를 사용한다면 인덱스 추가로 인한 데이터 저장/변경/삭제에 대한 비용이 발생합니다.
하지만 이후 요구사항 변경으로 발생할 수 있는 화면 레이아웃 변경, 복합키의 구성 및 값 변경에 좀 더 유연하게 대처할 수 있어서 영향도가 적을 것같습니다.
예를 들면, 주민번호를 변경할 수 있을 것이라고 생각하지 못했던 것 처럼 PK 구성은 예상치 못하게 바뀔 수 있습니다.

DB 성능도 중요하지만, 복합키 같은 경우 조금이라도 변경 영향도에 안전하다고 생각하는 방향으로 키를 구성하고 있습니다! 아직도 정답은 모르겠네요. 틈틈이 이런 주제에 대한 의견이나 논쟁(?)이 다뤄진 글이 있다면 첨부하겠습니다.

 

• Composite Primary key vs additional “ID” column?
• SQL - many-to-many table primary key