Merge pull request #30 from SSUMC-6th/reli/#7

[레리]Chapter 7. JPA를 통한 엔티티 설계, 매핑 & 프로젝트 파일 구조 이해

chapter7/keyword/chapter7_keyword.md

@@ -0,0 +1,64 @@
+- 영속성 컨텍스트
+
+    영속성 컨텍스트란 데이터를 영구 저장한다는 개념이다.
+
+    논리적인 개념이라 눈에 보이지 않으며 EntityManager를 통해 접근할 수 있다.
+
+    스프링 프레임워크 환경에서는 Entity Manager와 영속성 컨텍스트라 N:1 관계로 이루어져 있지만, concurrency는 잘 이루어져 있으므로 문제되지 않는다.
+
+    영속성 컨텍스트는 엔티티의 생명주기와도 연관이 있는데
+
+    - 비영속
+
+        영속성 컨텍스트와 전혀 관계가 없는 새로운 상태(만들어진 상태)
+
+    - 영속
+
+        영속성 컨텍스트가 관리하고 있는 상태
+
+    - 준영속
+
+        영속성 컨텍스트에 저장되었었으나 현재는 분리된 상태
+
+    - 삭제
+
+        삭제된 상태
+
+
+    와 관련이있다.
+
+    영속성 컨텍스트의 이점은 1차 캐시 역할을 하여 속도를 향상시켜주며, 동일성을 보장하고, 트랜잭션을 지원하는 쓰기 지연도 지원한다.
+
+    또한 영속상태의 객체는 변경이된다면 dirty checking을 통해 변경된 부분을 db에 반영해준다.
+
+    마지막으로 지연 로딩을 통해 연관된 객체를 한꺼번에 다 가져오지 않도록 하여 N+1 문제를 예방한다.
+
+- 양방향 매핑
+
+    양방향 매핑은 데이터베이스 입장에서 바라오면 쓸모없는 옵션이다. 데이터베이스의 경우 한쪽이 FK를 가지고 있으면 그 FK를 통해 양쪽다 쉽게 조회할 수 있기 때문이다.
+
+    하지만 객체는 한쪽에서 갖고있는다고 하더라도, 반대쪽에서는 조회하기가 어렵다. 그럴 경우 사용 할 수 있는 것이 양방향 매핑이다.
+
+    위에서 다뤘듯이 매핑을 한 객체에만 하는 것이 아닌 양 쪽에서 진행하는 것이다.
+
+    이렇게 만들어주면 어느 쪽에서든 객체 탐색을 용이하게 하는 효과가 있다.
+
+    물론 양쪽에서 매핑하게 할 경우 연관관계 주인을 정해주어야 하며, 1:N관계에서는 N쪽에, 1:1 관계에서는 프로그래머가 선택하여 연관관계 주인으로 삼으면 된다.
+
+    위에 dirty checking과 관련있는데 연관관계 주인이 아닌 곳에서 연관된 객체를 변경하더라도 반영되지 않는다. 즉 읽기 전용이다.
+
+    사용시 주의할점은 @toString 사용시에 무한루프에 빠질 수 있는 점이다. (서로가 서로를 참조하므로) 그러므로 이렇게 양방향 매핑을 사용할 경우, toString을 써야한다면 toString을 직접 구현하자
+
+- N + 1 문제
+
+    @ManyToOne 이나 @OneToOne 어노테이션을 사용할 때, fetch = FetchType.LAZY로 설정하는 이유다.
+
+    이 방식은 지연로딩이라고 하며, JPA를 통해 객체를 조회했을 때, 객체와 연관된 또다른 객체가 곧바로 조회되지 않고 임시로 프록시를 만들어서 조회되도록 만드는 기능을 한다.
+
+    이렇게 지연로딩을 사용하는 이유는 N+1문제와도 연관이 있는데 N+1 문제는 한가지 객체만 조회하려고 했지만, 예상치 못하게 다른 객체들 또한 한번에 조회되기 때문에 원래(1) + 연관된 객체(N)라고한다.
+
+    별거 아닌것처럼 보일 수 있는데 10000개의 데이터가 존재하는 객체에 10개의 연관된 객체가 있다고 한다면… 100000개의 쿼리가 나갈 것이다. 그리고 또 연관된 객체와 연관된 객체에 관한 쿼리도 추가된다면 쿼리양이 매우 많아질 수 있고 그러면 서버에 과부하가 걸리 수 밖에 없다.
+
+    그러므로 해당 문제가 발생하지 않도록 fetch = FetchType.LAZY를 잘붙여서 예방하자
+
+    참고로 OneToMany나 ManyToMany는 기본이 LAZY이므로 신경쓰지 않아도 된다.