jpa 다양한 연관 관계!!!!!

다대일 (@ManyToOne)

다대일 단방향 : FK 외래키 있는 곳(멤버테이블)을 객체에선 Team team 으로 객체에서 연관관계를 만들자. 가장 많이 사용하고 반대는 일대다 (OneToMany)

양방향 연관 관계를 맺기 위해 Team 객체에서도 멤버 리스트를 만들어 연관 관계를 성립 시켜준다.

mappedBy =”team” 팀에 의해서 연관되었다.

---

일대다 (@OneToMany)

다대일과 반대로 Team 테이블 Team 객체가 주인이 되는 연관 관계 그런데 이건 바람직하지 않다. List members 에 뭔가 바뀌었을 때 Member 에 있는 Team_id 도 업데이트 돼야 하기 때문에 별로다.

이렇게 연관관계를 만든다

개 억지 연관

멤버 객체의 팀을 억지로 읽기 전용으로 만들어서 연관 관계를 억지 만든거임. 다대일 양방향을 사용하자.

---

일대일 (@OneToOne)

주 테이블이나 대상 테이블 중에 외래 키 선택 가능

• 주 테이블에 외래키
• 대상 테이블에 외래키 외래 키에 데이터베이스 유니크 제약 조건 추가

멤버 테이블에 Locker_id 라는 fk 가 있으니깐 멤버 엔티티에 Locker locker를 만들었다.

양방향으로 만들고 싶다면 Locker 엔티티에서

mappedBy 쓰면 된다~

이제 반대 Locker 에 멤버 ID

단방향 관계는 JPA 가 지원 X 대신 양방향 관계는 지원 …

이렇게 양방향으로 맞춰줘서 member를 주인으로 잡으면 됨.

일대일 정리

주 테이블에 외래 키

• 주 객체가 대상 객체의 참조를 가지는 것 처럼 주 테이블에 외래키를 두고 대상 테이블을 찾음
• 객체지향 개발자 선호
• JPA 매핑 편리
• 장점 : 주 테이블만 조회해도 대상 테이블에 데이터가 있는지 확인 가능
• 단점 : 값이 없으면 외래 키에 null 허용

대상 테이블에 외래 키

• 대상 테이블에 외래 키가 존재
• 전통적인 데이터베이스 개발자가 선호
• 장점 : 주 테이블과 대상 테이블을 일대일에서 일대다로 변경할 때 테이블 구조가 유지됨
• 단점 : **프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨.

---

다대다(@ManyToMany) - 실무에서 쓰지 말자

객체는 멤버도 프로덕트 리스트, 프로덕트도 멤버리스트 가지면 되긴함;

이렇게 테이블을 만들어서 조인 해야 한다..

이러면 양방향

중간 테이블을 엔티티로 승격시키고 이제 각각 연관 관계를 만든다