⚡ 생각대로 살지 않으면 사는대로 생각한다.
⚡ 나는 어차피 잘 될 놈이다. 이미 잘 되고 있고, 계속해서 잘 되고 있다.
일대다 [1:N]
일(1)이 연관관계 주인.
일(1) 방향에서 외래 키를 관리함.
✅참고로 영한좌는 이 모델을 권장하지 않음.
일대다 단방향
객체 설계에서 Team은 Member를 참조해야 하지만, Member는 Team을 몰라도됨.DB 설게에서는 무조건 다(N)쪽에 외래 키가 들어가야 한다.
Team : Member는 1:N 관계로, Team을 통해서 MEMBER 테이블의 외래키인 TEAM_ID를 매핑한다.
퍼~렇게 드래그 쳐진 곳은 그렇다고 치는데,
슬래시로 도배된 라인 중간의
team.getMembers().add(member); 이 코드가 조금 낯설다..
Team쪽을 건드렸으니 TEAM 테이블에 쿼리가 나가야하는데, TEAM이 아니라 MEMBER 테이블에 외래키로 TEAM이 있기때문에, MEMBER 테이블에 쿼리를 날려준다.
값은 정상적으로 들어왔다. 하지만 쿼리가 좀 많이 나갔다.
왜 update 쿼리가 나가야하는가..??
이 코드에서
Team team = new Team();
team.setName("teamA");여기는 그냥 TEAM 테이블에 넣으면 되는데 문제는 아래 코드다..
team.getMembers.add(member);
사진과 같은 설계에서 Team Entity를 저장하는데, MEMBER를 update 칠 수 밖에 없다. 그래서 어쩔 수 없이 쿼리가 나갈 수 밖에 없다.
테이블이 수십개가 되는 실무상황에서는 이렇게 엮이게 되면, 운영이 힘들어진다.
영한좌는 다대일 단방향 관계 / 필요하면 양방향 추가하는 전략으로 간다.토비님, 영호님(객체지향의 사실과 오해, 오브젝트 저자)도 비슷한 생각을 하심...ㄷㄷ;;
일대다 단방향 정리
일대다 단방향은 일대다(1:N)에서 일(1)이 연관관계의 주인
테이블 일대다 관계는 항상 다(N)쪽에 외래 키가 있음
객체와 테이블의 차이 떄문에 반대편 테이블의 외래 키를 관리하는 특이한 구조
@JoinColumn을 꼭 사용해야함. 그렇지 않으면 조인 방식을 사용함(중간에 테이블을 하나 추가함)
-
-
@JoinColumn(name = "TEAM_ID")를 주석처리하고, 실행하면, 못 보던 테이블을 CREATE한다. -
일대다 단방향 매핑의 단점
- 엔티티가 관리하는 외래 키가 다른 테이블에 있음
- 이게 어마어마한 단점.
- 연관관계 관리를 위해 추가로 UPDATE SQL 실행
일대다 단방향 매핑보다는 다대일 양방향 매핑을 사용하자!!
일대다 양방향
※ 약간 억지..;;
Team도, Member도 연관관계 주인처럼 만들어주고, Member는 읽기 전용 매핑만 되도록 함.
코드는 아래와 같이 해주면 됨..
insertable, updatable을 붙이지 않으면, 둘다 연관관계 주인이 된다..
일대다 양방향 정리
이런 매핑은 공식적으로 존재 X
@JoinColumn(insertabl=false, updatable=false)
읽기 전용 필드를 사용해서 양방향처럼 사용하는 방법
※ 한 번씩 있긴있다..
하지만, 그럼에도 불구하고, 다대일 양방향을 사용하자!!
-끝-
