주인 테이블이나 대상 테이블 아무대나 선택해서 외래키 넣어도 됨.
외래키에 DB 유니크 제약조건 추가해야 함. 하긴. 1:1이니 고유해야 함.
예를 들자면 회원의 사물함.
1:1 관계
여기선 MEMBER테이블에 외래키를 넣었는데, 어디에 넣든지 상관 없음.
다대일과 유사하기도 함
@Entity
public class Member {
@Id @GeneratedValue
@Column(name = "MEMBER_ID")
private Long id;
@Column(name="USERNAME", nullable = false)
private String name;
@OneToOne
@JoinColumn(name = "LOCKER_ID")
private Locker locker;
}
이렇게 추가.
@Entity
public class Locker {
@Id
@GeneratedValue
private Long id;
private String name;
}
이렇게 단방향.
만약 양방향 하고 싶으면
@OneToOne(mappedBy = "locker")
private Member member;
이거 추가하면 됨.
다대일이랑 비슷함.
일대다에서 했던 것 처럼 역방향으로 꼬이게
이거는 아예 지원도 안됨. 그냥 외래키 있는 곳을 주인으로 하셈.
근데 둘다 외래키를 넣을 수 있는데,
MEMBER에 넣는게 좋냐, LOCKER에 넣는게 좋냐?
일단은, 보통 MEMBER는 호출하고, Locker도 지연처리로 호출될 수 있으니 괜찮음.
보통 MEMBER는 많이 호출하니..
아니면 다대일로 바뀔 가능성 생각해보셈.
만약 한 MEMBER가 지금은 LOCKER가 하나지만 나중에 여러 개 가질 것이 분명하면
LOCKER가 외래키를 가지고 있는게 나음.
근데 보통 MEMBER에 넣을듯. 1:1은.
주로사용하는 테이블에 외래키
객체지향 개발자가 선호한다.
JPA 매핑이 편리하다.
주 테이블만 조회해도 보조 테이블에 데이터가 있는지 확인 가능하다.
단점은 값이 없으면 외래키에 null을 허용한다. (?? 그냥 유니크화 시키면 되지 않나, not null이랑?)
보조테이블에 외래키 존재
DB개발자들이 선호한다.
주 테이블과 보조테이블을 일대일에서 일대다로 변경시에도 테이블 구조가 유지된다.
단점은 프록시의 지연로딩을 할수 없다(보통 member를 주로 호출하는데, 테이블도 MEMBER만 호출하려고 했는데 참조할 외래키가 없어 LOCKER또한 뒤져야 함.)
DB분들과 뭘로할지 협의가 되어야 한다.
'JPA > JPA 기본' 카테고리의 다른 글
23. 실전3 다양한 연관관계 매핑 (0) | 2023.10.25 |
---|---|
22. N : M 다대다 연관관계 (0) | 2023.10.25 |
20. 1:N 일대다 (0) | 2023.10.24 |
19. N : 1 다대일, 다양한 연관관계 (0) | 2023.10.24 |
18. 실전2 객체구조를 외래키에서 참조로 (1) | 2023.10.24 |