복합키 vs 정수형 단일 기본 키 (with UNIQUE)

스크린샷 2025-04-20 오후 5.43.25.png

❓ 여기서 현재처럼 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 등)	복합키 지원은 복잡하고 불편함
확장성	유연하게 확장 가능 (예: 상태 컬럼 등 추가 시)	구조 단순하지만 유연성 떨어짐

대부분의 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