공부하는 개발자 핑구 🐧 공부하는 개발자 핑구 🐧

* 복합키 구현시 equals()와 hashCode() 메소드는 복합키 비교에서 사용되므로 꼭 Override해주자. 필자는 복수전공자라 시간표도 안맞고 학점채우기에 급급해 데이터베이스과목을 수강하지 못했다. 그래서 혼자 SQLD 라도 공부하고 자격증을 따면 비등하지 않을까 했는데... 튜닝부분이 핵심인 것을 이제야 깨닫는 중이다. 추후에 데이터베이스 성능튜닝에 대한 공부를 할 것이지만, 그에 앞서 JPA로 간단한 성능측정을 해보았다. 필자가 구글링을 통해 알아낸 정보에 기반한 실험이다. (카더라 통신일 경우가 많으므로, 추후 검증이 필요하다) 1. 검색조건에 자주 등장하는 컬럼은 인덱스처리를 하면 검색성능이 빨라진다. 2. 인덱스처리를 하면, 데이터 삽입/수정/삭제 마다 B-Tree 자료구조를 유지해야..

JPA에서는 연관관계를 맺으면 연관관계를 맺은 두 테이블 중 하나에 FK필드를 디폴트로 생성하게 된다. @MapsId를 이용해 디폴트로 생성 될 컬럼을 줄이고, 그 값을 PK에 주입할 수 있다. (그리고 두 테이블은 FK로 연결되어 있지 않다.) # 엔티티 구조 # 테스트 코드 및 결과 mainEngine의 id=1 은 Car의 PK값인 1을 주입 받은 것이다. (보기좋게 Car의 Id를 직접세팅해줄 걸 그랬다.) select쿼리를 보면 join 이 없다. 이를 통해 mainEngine의 id는 foriegnKey 설정이 안되있음을 짐작할 수 있다. (JPA는 FK로 연결된 객체는 join문으로 가져온다.) # DDL-auto 로 생성된 테이블 구조 Hibernate: create table car ( ..

>> @OneToMany에서 @MapsId 올바르게 사용하는법 보러가기 >> @OneToOne에서 @MapsId 로 컬럼갯수 1개 줄여보기 @MapsId 에 관하여... @MapsId는 FK를 PK로 지정할 때 사용하는 어노테이션이다. 이 말은 즉슨, @MapsId를 통해 엔티티의 PK를 FK로 매핑한다면, 데이터베이스 컬럼하나를 줄일 수 있다는 이야기이다...! @MapsId를 검색하다가 @OneToMany 와 같이 검색어가 자동완성되기에, 이거 되는거구나!! 대박인걸!! 하고 웹상에 존재하는 예시코드를 따라해보았다. 결론부터 말하면, @OneToMany에서의 @MapsId 사용은 PK가 복합키일때만 사용가능하며, 위의 데이터베이스 컬럼하나를 줄일 수 있는 효과는 없다. @OneToOne에서는 @Map..

본론부터 말씀드리자면 referencedColumnName을 사용하여 엔티티를 연결한 경우 정체모를 쿼리가 하나 더 나간다. 이 현상이 왜 발생하는지, 그리고 이를 어떻게 해결하는지에 대한 포스팅이다. (해결방법은 찾지 못했다 😢) [들어가기 앞서] referencedColumnName 은 비식별관계 FK 를 만들때 사용한다. 꼭 FK만 사용하는건 아니고, 영문 그대로 레퍼런스로 참조할 칼럼을 선택하는 것이다. 코드로 예를 들어보겠다. # Child 엔티티 @Entity @Getter @Setter @NoArgsConstructor @ToString public class Child { @Id @GeneratedValue(strategy=GenerationType.IDENTITY) Long id; Str..

상속관계 매핑에 대한 글은 이전에 한번 쓴적이 있다. [Spring JPA] 슈퍼-서브타입 관계 모델링 (상속관계 매핑) DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데, 논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다. [SQL] 슈퍼-서브타입 모델의 developer-ping9.tistory.com "와 완전 좋잖아!!' 라고 극찬을 하며 개인적으로 진행중인 프로젝트에 적용하고자 코드를 다 뜯어고치면서 찾은 문제점을 공유하고자 한다. # @Inheritance(strategy = InheritanceType.JOINED) 의 문제점 1. Super타입클래스만 따로 조회할 수 없다. (Lazy Fetch가 안된다...

DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데, 논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다. # 논리모델 * 전구모양의 x는 exclusive (x가없으면 inclusive) # RollUp (Single-Type) 하나의 테이블로 통합 # RollDown (Plus-Type) 슈퍼타입을 각각의 서브타입에 추가하여 분리 # Identity (One-To-One Type) 슈퍼타입과 각각의 서브타입을 테이블로 생성 # 슈퍼-서브타입 모델 비교 # 물리모델 결정기준 데이터의 양과 트랜잭션의 유형에 따라 선택한다. 1. 개별로 발생되는 경우가 많은 서비스는 Identity로 ! 위의 논리모델에서 예를 들자면, 아이..

DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데, 논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다. [SQL] 슈퍼-서브타입 모델의 물리모델 결정기준 (feat. JPA) DB 모델링기법 중에 슈퍼-서브타입 모델링(엔티티가 상속관계를 이룸)이라는게 있는데, 논리모델은 같지만 실제 물리모델은 RollUp, RollDown, Identity 중 하나로 구현한다. # 논리모델 * 전구모양의 x developer-ping9.tistory.com 즉, 물리모델중 어느 방법으로 구현하냐에 따라서 테이블의 구조와 갯수가 변동된다. 실제 서비스 중, 성능이 너무 안나와서 다른 물리모델로 교체하자라는 콜이 나왔을 때 JPA가 없다면..

# 단방향으로 해? 양방향으로 해? 테이블의 관점에서 보면, 외래키하나로 양쪽 조인이 가능하기에 단방향이나 양방향이나 의미가 없다. 하지만 객체입장에선 참조용 필드가 있는쪽으로 참조가 가능하기에 어느쪽에서 참조가 필요하냐에 따라 결정한다. 양방향은 사실상 단방향이 2개인 것과 같다. # 연관관계의 주인 양방향으로 관계를 어노테이션으로 설정시에, ORM은 어느테이블에 FK를 생성해야할지 알 수가 없다. 그러므로 당연히 명시적으로 지정해주어야 한다. 연관관계의 주인쪽 테이블에 FK가 생성된다. # 실무에서의 적용 N:1 단방향과 양방향만 사용한다. 1:N 이 필요할때(읽기전용)는 단방향이 아닌 N:1 양방향으로 걸어주어야 한다. * 자세한 이유는 아래 포스팅을 참조 1:N을 단방향으로 걸게되면 1인쪽이 매핑..