일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 유니티
- 이분탐색
- Unity2D
- Photon
- QueryDSL
- Inventory
- C++
- 스택
- UE4
- 포톤
- Unity3d
- 해시
- Firebase
- Unity
- 워크플로
- UnrealEngine
- c#
- 구현
- 프로그래머스
- 스파르타내일배움캠프TIL
- 유클리드호제법
- FSM
- 순열
- unityui
- 알고리즘
- 문자열
- BFS
- 내일배움캠프
- 스파르타내일배움캠프
- 언리얼엔진
- Today
- Total
개발 낙서장
[TIL] 내일배움캠프 63일차 - 논리적 참조키 본문
오늘의 학습 키워드📚
논리적 참조키, 물리적 참조키
보통 RDB의 가장 큰 특징이 무엇이냐 하면 여러 가지를 답할 수 있겠지만 그중 하나가 테이블 간 관계를 맺을 수 있다는 점이다.
RDB의 대표격인 MySQL에서 테이블들의 모든 데이터는 Primary Key를 갖고 있다.
이 때 다른 테이블에서 해당 테이블의 데이터를 갖고 있다는걸 표시하는 컬럼이 '참조 키'이다.
말 그대로 다른 데이터를 참조한다는 것인데 그걸 키 값으로 표현한 것이다.
참조 관계를 맺어 테이블을 구성하면 보통 참조 관계와 제약 조건을 설정하게 되는데 이는 참조 무결성을 위함이다.
참조 무결성이란 참조 키와 기본 키는 항상 일치해야 하며 어느 하나만 수정, 삭제될 수 없음을 말하는데 이를 물리적인 참조라고 (내가)한다.
RDBMS에서는 시스템적으로 제약 조건을 통해 해당 참조 무결성을 지키고 있다.
하지만 아이러니하게도 이런 참조 제약 조건을 없앨 수도 있다.
즉, 다른 테이블의 참조 키를 갖고는 있지만 무결성이 위반되더라도 시스템은 문제 없이 돌아가는데 이것을 논리적인 참조라고 (내가)부른다.
논리적인 참조의 개념이 생긴 이유는 물리적인 참조에서 나오는 몇몇 단점 때문인데
1. 데이터의 추가, 수정, 삭제 작업에 약간의 시간이 더 소요된다
시스템적으로 참조 무결성이 위배되는지를 검증해야 하기 때문에 당연히 데이터의 CUD 작업 시 약간의 시간이 더 소요된다.
물론 정말 대용량의 데이터를 다루는 것이 아니라면 크게 문제되는 수준은 아니다.
2. 테이블의 구조를 변경하기 쉽지 않다.
테이블을 쪼갠다거나 합치는 등 테이블의 구조 변경에 무겁다. 특히 참조 관계가 복잡할 수록 더욱 변경하기 어려워진다.
3. 테스트 코드
참조 무결성 원칙은 당연하게도 테스트 코드에도 적용이 되는데
극단적인 예로 A 테이블을 B가 참조하고 B를 C가 참조하고 C를 D가 참조하고 ...........
이 때 K 테이블에 대한 테스트를 하려면 앞에 있는 모든 테이블의 데이터를 최소 하나라도 추가하면서 테스트를 진행해야 한다.
이는 테스트 시 엄청난 불쾌감으로 다가온다. 내가 논리적 참조를 고민한 이유도 테스트 때문이 크다.
논리적 참조 맺기
JPA Entity를 통해 논리적 참조 관계를 맺는 방법은 두 가지가 있다.
1. @ForeignKey 어노테이션을 통해 제약 조건 없애기
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id", foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
private User user;
Entity 클래스에서 다른 테이블을 다대일 관계로 참조할 때 위의 어노테이션을 사용하게 되는데
foreignKey 옵션을 통해 참조키 제약 조건을 없애는 방법이 있다.
2. Long 타입으로 필드 생성하기
@Column
private Long userId;
다른 컬럼을 만드는 것처럼 Long(bigint) 타입으로 생성하는 것이다.
두 방법 모두 DB에는 같은 형태로 저장된다.
이렇게 실제 DB에는 일반 bigint 타입 컬럼으로 들어가게 된다.
DB 안에서는 그냥 컬럼 형태지만 기능을 구현할 때는 다른 테이블의 PK를 활용하는 것처럼 구현할 수 있다.
주의할 점은 참조 무결성이 위배되더라도 시스템적인 에러가 발생하지 않기에 데이터의 정확성을 검증을 통해 보장해야 하며 참조키 인덱싱이 따로 설정되지 않기에 인덱스를 생성해주지 않으면 조회나 Join 쿼리 시 전체 탐색을 하게 된다.
오늘의 회고💬
반려동물 통합 커뮤니티에 대한 기능들을 구현하는 팀 프로젝트가 시작됐다.
오늘까지도 기능들에 대한 기획과 기본 틀을 잡느라 계속해서 회의만 했다.
내일의 계획📜
내일부터 본격적으로 팀 프로젝트를 시작하게 되는데 나는 오픈 채팅 도메인을 맡았다.
소켓 통신을 이용해야 해서 새로운 도전이 될 것 같아 재밌을 것 같다.
'Java > Sparta' 카테고리의 다른 글
[TIL] 내일배움캠프 65일차 - STOMP JWT 인증 (0) | 2024.03.29 |
---|---|
[TIL] 내일배움캠프 64일차 - STOMP로 실시간 채팅 구현 (0) | 2024.03.28 |
[TIL] 내일배움캠프 62일차 - Open API (0) | 2024.03.26 |
[TIL] 내일배움캠프 61일차 - 참조키 인덱싱 (0) | 2024.03.25 |
[TIL] 내일배움캠프 60일차 - 통합 테스트 (0) | 2024.03.22 |