20230210 JPA 설명

JPA는 귀찮은 작업들을 처리해주는 편리한 도구.
예를 들면, 지금 코드에 있는 Product라는 것도 관계형 데이터베이스에 있는 하나의 row인데
쿼리를 직접 짤 필요 없이 객체 단위로 저장을 하거나 조회를 하고, 
객체 째로 주면 jpa가 알아서 Insert 쿼리를 날려주고,
조회를 한다고 하면 그 row를 다시 객체로 변환하는 귀찮은 작업들을 도와주는 것도 맞다.

"패러다임 불일치"
데이터베이스에서 보는 객체는 하나의 row인데, 객체에서는 하나의 클래스(다름) 
이 부분을 자동 변환을 통해 해결해줌.

그런데 이러한 작업을 하려면,
적어도 "데이터베이스에 있는 이 row는 클래스와 어떻게 매핑이 될 거야" 라고 하는
최소한의 정보는 줘야 해.
그게 이제 "매핑 관계 설정" 이 되는 거지.

@Entity 가 붙어있으면, 하나의 테이블이라고 인식하게 되는 거고,
@Id 가 붙어있으면, 모든 엔티티에서는 하나의 기본키가 붙어있어야 하는데, 
그 기본키 값이라는 것을 알려줌.

그리고 모든 필드 위에는 @Column 어노테이션을 붙이는데,
생략되어 있으면 자바 컴파일러가 자동으로 붙여주고 있다고 생각하면 된다.
이건 연관관계 매핑이 아니라 테이블과 클래스 연관시킨 것

이제 연관관계 매핑으로 들어가서,
"한 명의 사용자가 여러 개의 상품을 가질 수 있나?" Yes!

지금 우리 팀 ERD를 보면,
한 명의 User가 여러 개의 Product를 가질 수 있는 구조로 설계되어 있다.

그럼 어떤 사용자가 몇 개의 상품을 가진다를 데이터베이스 쪽에도 표현을 해줘야 해.
그럼 어떻게 어디에다가 표현을 해줄거냐 라는 문제 발생

"사용자에서 관리를 한다고 하면"
하나의 컬럼에 여러개의 값들이 들어갈 수 밖에 없다.

 사용자 쪽에서 관리하는 걸 표현한다면

정리하기가 매우 까다롭다.

 

그래서 "일대 다" 매핑일 때는
"Many 쪽에서 관리하는 게 훨씬 편리하다!"

왜냐하면 유저 테이블에서는 
상품을 1개 가진 고객도 있고, 없는 고객도 있고, 10개 이상 가진 고객도 있을 테니
다 다르면 복잡...

그래서 User 입장에서는 아예 상품에 관심이 없고,
상품 쪽에 하나의 컬럼을 만들어서
이 상품의 User가 누구인지를 여기다가 기록을 하겠다는 것.

그래서 User 클래스의 @OnetoMany는
"나(User)는 하나고 상대방(Product)는 여러 개다" 라는 것을 표현한 것.
Set<Product>로 받았으니 더욱 확실하게 보이지.

그런데 이걸 Product 입장에서 보자면
하나의 Product는 반드시 하나의 User을 가질 테니,
"내가(Product) 여러 개 이고, 상대(User)가 하나이다"

관계는 언제나 두 개 사이의 관계만 신경 쓰면 된다.
연관관계는 DB에서 보면 항상 다(Many) 쪽에서 연관관계를 가지고 있다.
=> "연관관계의 주인"
물론 클래스에서는 양 쪽에 다 어노테이션으로 표기를 해 주지.

그래서 DB에서 User 쪽에 사용자 정보를 세팅을 해줘봤자 업데이트가 안 됨.