외래키 꼭 필요한가?
프로젝트를 하면서 '외래키 설정이 꼭 필요한가?' 라는 의문을 갖게 되었다.
물론 내 프로젝트처럼 소규모는 데이터 정합성과 무결성을 위해서 사용해도 성능상 큰 문제는 없다.
그럼에도 불편한 점이 존재한다.
초반 프로젝트를 막 설계하고 적용한 후 변경사항이 없을 수가 없고, 이로 인해 테이블을 변경하게 되는데
부모 테이블을 삭제하려니 FK 조건때문에 막히고,
테스트 시 현재 테스트에서 관심사가 아닌 연관관계가 설정된 테이블의 데이터도 함께 넣어줘야하므로
생각보다 번거롭다고 느꼈다. <-- 이게 좀 큰 것 같다.
특정 부모를 참조하는 자식데이터들의 대량 insert 발생 (ex 댓글)
데이터
무결성 (Integrity) : “데이터 자체가 논리적으로 올바른가?” — 잘못된 값이 들어오지 않도록 보호하는 제약 조건
정합성 (Consistency) : “서로 다른 데이터 간에 모순이 없는가?” — 시스템 전반의 데이터 일치 상태
FK가 어떤 프로세스로 진행되는지 알아보자
FK 검증시 InnoDB가 실제로 하는 일
자식 INSERT/ UPDATE
- 자식 테이블에 데이터를 넣을 때 InnoDB는 부모 테이블의 참조 키가 존재하는지 인덱스로 조회
- 부모 레코드에 S(Shared) 레코드 락
- 이로 인해 부모 삭제/ 키 변경 시 X-락 필요로 S-락과 경합이 발생
부모 DELETE/ 키 UPDATE
- 부모를 지우거나 참조 키 변경시 InnoDB는 자식 쪽에 참조가 남아 있는지 자식 FK 인덱스 검사
- RESTRICT/NO ACTION : 자식 FK 인덱스 범위를 읽고 잠금 (참조 존재시 에러)
- ON DELETE/UPDATE CASCADE : 자식 레코드들을 직접 DELETE/ UPDATE (대량 잠금/수정)
- 부모 레코드 X-락 필요, 자식 다량의 레코드, 넥스트 키 락 전파
물론 신뢰성과 무결성이 중요한 거래등의 데이터는 FK를 설정해서 안전하게 처리하는 게 맞다.
하지만 거래가 아닌 게시글, 댓글 등 CRUD가 빈번하게 일어나는 테이블에 대해서 FK를 설정하여
성능 저하가 발생하는 것은 좋지 않다고 생각이 든다.
이에 따른 단점
- 애플리케이션 단에서 검증 비용 발생
- JPA 사용시 그래프 탐색, Fetch Join 불가
- 무결성 보장 X
- CASCADE 불가
정도로 생각된다.
다음 프로젝트에서는 FK 없이 개발을 해보려한다.
JPA에서 어떻게 사용할 것인가?
각 엔티티는 생성하되 연관관계 매핑을 하지않고, member_id 처럼 외래키 값만을 이용해서 처리한다.
이로 인해 그래프 탐색, 엔티티 조인이 막히지만
QueryDSL로 직접 ON 으로 id값을 연결해서 조인하면 된다.
'Back-End > DB' 카테고리의 다른 글
| MYSQL DB 명 변경 (0) | 2025.11.07 |
|---|---|
| Real My SQL 8.0 [공간 데이터] (1) | 2025.09.25 |
| Real MySQL 8.0 [실행계획 : Extra 칼럼] (0) | 2025.09.03 |
| Real MySQL 8.0 [실행계획] (4) | 2025.09.01 |
| 락에 대하여 (0) | 2025.08.20 |