
❓ 여기서 현재처럼 PK를 따로 둘 것인가 vs 복합키로 할 것인가?
|
단일 PK (id ) 방식 |
복합키 (channel_room_id , user_id ) 방식 |
식별자 |
정수형 단일 id 로 명확히 식별 |
두 컬럼 조합으로만 유일 식별 가능 |
JOIN 편의성 |
단일 키로 참조/JOIN 쉬움 |
JOIN 시 항상 두 컬럼 조건 필요 |
중복 방지 |
중복 방지는 따로 UNIQUE 제약 걸어야 함 |
중복 자체가 PK 위반이라 자동 방지 |
인덱스 구조 |
PRIMARY KEY(id) + INDEX(channel_room_id, user_id) 필요 |
PRIMARY KEY(channel_room_id, user_id) 만으로 충분 |
ORM 매핑 |
대부분의 ORM은 id 를 선호함 (JPA, Hibernate 등) |
복합키 지원은 복잡하고 불편함 |
확장성 |
유연하게 확장 가능 (예: 상태 컬럼 등 추가 시) |
구조 단순하지만 유연성 떨어짐 |
✅ 분석 결과 → 단일 id(PK)
방식이 적합!
- 대부분의 ORM (JPA, Sequelize, TypeORM 등)을 사용할 때
- 특히
JPA
, Hibernate
, TypeORM
같은 ORM에서는 복합키는 @IdClass, @EmbeddedId 등 복잡한 설정이 필요함 → 클래스 하나 더 만들고, equals(), hashCode()도 오버라이딩해야 하고, 오류도 많음
- 관리 편의성을 중요시할 때
- 추후 이 테이블에 기능이 더 추가될 가능성 있을 때 (예: 채팅방 입장 시간, 권한, 상태 등)
👉 지금처럼 id
를 PK로 두고, 대신 channel_room_id
, user_id
에 UNIQUE 제약 조건을 걸면 중복도 막고 유연성도 확보할 가능.
ALTER TABLE channel_join
ADD CONSTRAINT uq_channel_user UNIQUE (channel_room_id, user_id);
+ 실무에서의 선택 기준 요약
조건 |
추천 방식 |
ORM 사용하는 웹 백엔드 (Spring, Node 등) |
id PK + UNIQUE 복합키 |
단순 SQL 기반 시스템 / OLAP 분석용 |
복합키 PK |