다양한 연관관계 - 일대일

일대일 관계는 그 반대도 일대일으로 주 테이블이나 대상 테이블 중 어느 곳에 외래 키가 있어도 상관없다. (여기서 주 테이블이란 주로 조회하는 테이블을 말함) 그러나 어느 테이블에 있느냐에 따라 매핑 방법은 달라질 수 있다.

 

★ 주 테이블에 외래 키 단방향

- Member가 주 테이블이고 Locker가 대상 테이블이라고 가정할 때, MEMBER 테이블에 외래 키가 존재하고 단방향이라고 가정하면 굉장히 단순하게 사용할 수 있다.

Member 엔티티

- 다대일 단방향을 설정할 때처럼 어노테이션만 다르게 설정해주면 끝이다.

 

 

★ 주 테이블에 외래 키 양방향

- 이 관계 역시 다대일 양방향 매핑처럼 Locker 객체에 Member 객체만 참조하면 완성이다.

locker 엔티티

 

 

★ 대상 테이블에 외래 키 단방향

- 이런 관계는 매핑할 수 있는 방법도 없고 JPA에서도 지원하지 않는다.

 

 

★ 대상 테이블에 외래 키 양방향

- 사실 이 관계는 일대일 주 테이블에 외래 키 양방향과 일치하는 방식이다. 연관관계의 주인이 Locker가 될 뿐이다.

locker 엔티티

member 엔티티

 

 

★ 일대일 정리

• 주 테이블에 외래 키
  - 주 객체가 대상 객체의 참조를 가지는 것처럼 주 테이블에 외래 키를 가지고 대상 테이블을 찾음
  - 객체지향 개발자가 선호하며 JPA 매핑이 편리함
  - Member 테이블만 조회해도 Locker 값이 있는지 없는지 확인할 수 있기 때문에 편리함
  - 값이 없으면 null 값이 들어가므로 좋지 않을 수 있음
• 대상 테이블에 외래 키
  - 대상 테이블에 외래 키가 존재함
  - 일대일에서 일대다 관계로 확장되었을 때 테이블 구조를 유지할 수 있으므로 데이터베이스 개발가 선호함
  - 프록시 기능의 한계로 지연 로딩으로 설정해도 항상 즉시 로딩됨
  (아직 프록시에 대해 자세히 배우지 않아서 정확히는 모르겠지만, JPA를 실행할 때 Locker에 값이 있는지 없는지를 확인하고 값이 없으면 null을 넣어줘야하는데 대상 테이블에 외래 키가 존재하면 알 수 없으므로 어차피 Locker 테이블을 한번 훑는 쿼리를 실행해야하므로 지연 로딩을 하는게 의미가 없는 것으로 이해된다)