From d2e1c02720beb7363add6a615fa9075965e68d3a Mon Sep 17 00:00:00 2001 From: hw130 Date: Sun, 30 Jul 2023 12:17:35 +0900 Subject: [PATCH] =?UTF-8?q?=F0=9F=8E=A8=20[Style]:=20Paragraph=20error=20c?= =?UTF-8?q?orrection(#6)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../Note.md" | 25 +++++++++++++------ 1 file changed, 17 insertions(+), 8 deletions(-) diff --git "a/Session 06 - \353\213\244\354\226\221\355\225\234 \354\227\260\352\264\200\352\264\200\352\263\204 \353\247\244\355\225\221/Chapter 02 - \354\235\274\353\214\200\353\213\244/Note.md" "b/Session 06 - \353\213\244\354\226\221\355\225\234 \354\227\260\352\264\200\352\264\200\352\263\204 \353\247\244\355\225\221/Chapter 02 - \354\235\274\353\214\200\353\213\244/Note.md" index 4719978..7873733 100644 --- "a/Session 06 - \353\213\244\354\226\221\355\225\234 \354\227\260\352\264\200\352\264\200\352\263\204 \353\247\244\355\225\221/Chapter 02 - \354\235\274\353\214\200\353\213\244/Note.md" +++ "b/Session 06 - \353\213\244\354\226\221\355\225\234 \354\227\260\352\264\200\352\264\200\352\263\204 \353\247\244\355\225\221/Chapter 02 - \354\235\274\353\214\200\353\213\244/Note.md" @@ -15,11 +15,16 @@ ### 일대다 단방향 --- - 팀과 회원(일대다) 관계라고 생각했을 때, 팀은 모든 회원들을 참조하지만 회원들은 팀을 참조하지 않으면 이를 일대다 단방향이라 한다. -스크린샷 2023-07-30 오후 12 04 43 -- 위와 같은 그림이 나오게 된다. 왜냐하면 참조는 Team이 가지고 있는데(객체) 반면, 일대다 관계에서 외래 키는 항상 다쪽 테이블에 존재하기 때문이다. 따라서 크로스 되는(매핑한 객체가 관리하는 외래 키가 다른 테이블에 있는 경우) 상황이 발생한다. -- 본인 테이블에 외래 키가 있으면 엔티티 저장과 연관관계 처리를 INSERT 쿼리 한 번으로 끝낼 수 있지만, 다른 테이블에 외래 키가 있으면 연관관계 처리를 위한 UPDATE 쿼리를 추가로 실행해야 한다. - - 첫 번째 Update 쿼리: 새로운 멤버의 데이터를 멤버 테이블에 삽입한다. 이 때, 멤버 테이블의 외래 키를 해당 멤버가 속한 팀의 기본 키로 설정한다. (즉, 팀과 멤버 테이블을 연결한다.) `INSERT INTO MemberTable (멤버 이름, 팀 ID) VALUES ('Tom', 1);` - - 두 번째 Update 쿼리: 팀 테이블의 데이터를 업데이트하여 해당 팀의 멤버 수를 증가시킨다. 이 때, 팀 테이블의 외래 키를 사용하여 연관된 멤버 수를 변경한다. `UPDATE TeamTable SET 멤버 수 = 멤버 수 + 1 WHERE 팀 ID = 1;` +스크린샷 2023-07-30 오후 12 04 43 + +- 위와 같은 그림이 나오게 된다. 왜냐하면 참조는 Team이 가지고 있는데(객체) 반면, 일대다 관계에서 외래 키는 항상 다쪽 테이블에 존재하기 때문이다. 따라서 크로스 되는(매핑한 객체가 관리하는 외래 키가 다른 테이블에 있는 경우) 상황이 발생한다. + +- 본인 테이블에 외래 키가 있으면 엔티티 저장과 연관관계 처리를 INSERT 쿼리 한 번으로 끝낼 수 있지만, 다른 테이블에 외래 키가 있으면 연관관계 처리를 위한 UPDATE 쿼리를 추가로 실행해야 한다. + + - 첫 번째 Update 쿼리: 새로운 멤버의 데이터를 멤버 테이블에 삽입한다. 이 때, 멤버 테이블의 외래 키를 해당 멤버가 속한 팀의 기본 키로 설정한다. (즉, 팀과 멤버 테이블을 연결한다.) `INSERT INTO MemberTable (멤버 이름, 팀 ID) VALUES ('Tom', 1);` + + - 두 번째 Update 쿼리: 팀 테이블의 데이터를 업데이트하여 해당 팀의 멤버 수를 증가시킨다. 이 때, 팀 테이블의 외래 키를 사용하여 연관된 멤버 수를 변경한다. `UPDATE TeamTable SET 멤버 수 = 멤버 수 + 1 WHERE 팀 ID = 1;` + ### 일대다 단방향 단점 @@ -32,9 +37,13 @@ ### 일대다 양방향 --- 스크린샷 2023-07-30 오후 12 06 00 -- `@JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)` 와 같은 읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법 -- 결론부터 말하자면, 일대다 양방향은 존재하지 않는다. 실제로 @ManyToOne 어노테이션에는 mappedBy 속성이 없는데, 이는 이 관계에서 One 쪽이 연관관계의 주인이 될 수 없음을 시사한다. -- 이유는 당연히 항상 다 쪽에 외래 키가 존재하기 때문이다. 따라서 @ManyToOne, @OneToMany 중 mappedBy를 쓸 수 있는 곳은 @OneToMany 뿐이다. + +- `@JoinColumn(name = "TEAM_ID", insertable = false, updatable = false)` 와 같은 읽기 전용 필드를 사용해서 양방향 처럼 사용하는 방법 + +- 결론부터 말하자면, 일대다 양방향은 존재하지 않는다. 실제로 @ManyToOne 어노테이션에는 mappedBy 속성이 없는데, 이는 이 관계에서 One 쪽이 연관관계의 주인이 될 수 없음을 시사한다. + +- 이유는 당연히 항상 다 쪽에 외래 키가 존재하기 때문이다. 따라서 @ManyToOne, @OneToMany 중 mappedBy를 쓸 수 있는 곳은 @OneToMany 뿐이다. + - 따라서 일대다(일이 연관관계의 주인) 관계로 설정하는 것은 다대일로 설정하는 것에 비해 단점이 많고, 일대다로 할 수 있는 것들은 당연히도 다대일로 전부 표현이 가능하기 때문에 다대일로 하는 것이 좋다. ### 결론 및 정리