High-Quality-Coffee

[Entity] 지금 나에게 필요한 데이터를 가져오자 - 지연로딩, 즉시로딩 (5)

지연로딩과 즉시로딩을 알아봅시다 위의 사진과 같은 관계를 가진 엔티티가 있다고 하자. 음식과 고객엔티티는 N 대 1 양방향 관계이다. @Testvoid test1() { Food food = foodRepository.findById(2L).orElseThrow(NullPointerException::new); System.out.println("food.getName() = " + food.getName()); System.out.println("food.getPrice() = " + food.getPrice());} 위 코드 처럼 음식에 대한 정보를 얻고 싶을 때, 쿼리를 확인해보면 아래와 같다 내가 조회하고자 하는 값은 음식엔티티인데, 음식엔티티와 매핑된 고객엔티티의 정보..

N 대 M 관계는 @ManyToMany 어노테이션으로 관계를 맺어줄 수 있다. 음식 Entity와 고객 Entity가 N 대 M 관계라 가정하겠다. 단방향 관계 여기서 이전에 못보던 주문테이블이 하나 생겼다. N 대 M 관계를 맺어주기 위해서는 중간 테이블이 필요한데 주문테이블을 중간테이블로 만들었다 아래 코드와 같이 작성하면 중간테이블인 주문테이블은 자동으로 생성된다. @JoinTable 어노테이션을 통해서 중간테이블을 생성할 수 있다. 음식@Entity@Table(name = "food")public class Food { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; priva..

이번에는 1 대 N 관계에 대해서 포스팅 하려고 한다. 1 대 N 관계는 @OneToMany 어노테이션을 사용해서 관계를 맺을 수 있다. 음식 엔티티와 고객 엔티티가 1 대 N 관계를 맺고,외래키의 주인은 음식엔티티라고 가정하겠다. 단방향 관계 그림을 보면 이상한 점을 발견할 수 있다. 우리는 N의 관계에 있는 엔티티가 외래키의 주인이 된다는 것을 알고있다. (바로 직전 포스팅에서 확인 가능) 그런데 우리는 외래키의 주인은 음식엔티티로 설정했는데 고객엔티티가 외래키를 갖고 있는 것이다. 이 경우에는, N의 관계에 있는 엔티티가 외래키를 가질 수 있으니,N의 관계인 고객엔티티가 외래키를 가지고 외래키의 주인인 음식엔티티을 통해 외래키를 관리한다. 외래키의 주인은 음식엔티티로 설정하여 음식엔티..

이번에는 N 대 1 관계에 대해서 포스팅 해보려고 한다. Entity에서 외래 키의 주인은 일반적으로 N(다)의 관계인 Entity 이다. 그 이유는 여러가지가 있는데, 그냥 직관적으로 그렇게 아는 것이 좋다. 이유는 아래와 같다. 더보기1. 데이터 무결성 보장1:N 관계에서 N쪽 Entity가 외래 키를 가지는 것은 참조 무결성(Referential Integrity)을 유지하기 위한 핵심적인 설계 방식입니다. N쪽 Entity가 1쪽 Entity의 기본 키(Primary Key)를 외래 키로 참조하면, 1쪽의 데이터가 존재하지 않는 경우 N쪽 데이터가 추가될 수 없도록 데이터베이스가 제약을 걸 수 있습니다.반대로, 1쪽 Entity에 N쪽 Entity를 참조하는 외래 키를 두는 것은 비효율적이며,..

1 대 1 관계에 대해서 알아보고자 한다. 1 대 1 관계를 맺어주기 위해서 @OneToOne 어노테이션을 사용한다. 고객엔티티와 음식엔티티가 1대1 관계를 가진다는 것을 가정하고 설명하겠다. 단방향, 양방향 기준으로 작성할 예정인데,방향 개념이 기억이 잘 나지 않는다면 아래 글을 보고 오자엔티티 방향개념이 잘 기억나지 않는다면! 단방향 관계 아래와 같이 단방향 관계를 갖는 엔티티가 있다고 해보자. Entity에서 외래 키의 주인은 일반적으로 N(다)의 관계인 Entity 이지만1 대 1 관계에서는 외래 키의 주인을 직접 지정해야 한다. 외래 키 주인만이 외래 키 를 등록, 수정, 삭제할 수 있으며, 주인이 아닌 쪽은 오직 외래 키를 읽기만 가능하다. 위의 그림에서는 외래키의 주인으로 음식엔..

DB 테이블간의 연관관계와 Entity간의 연관관계에서, 방향관계의 의미는 다르다고 볼 수 있다. 결론부터 말하자면, DB 테이블 사이의 연관관계는 FK로 맺을 수 있고,서로 방향 상관없이 조회 가능하다. 하지만, Entity에서는 상대 Entity를 참조해야 연관관계를 맺을 수 있고,그렇지 않다면, Entity를 조회할 수 있는 방법이 없다.그래서 방향이 존재한다. 연관 관계 고객 테이블idname1Robbie2Robbert 음식 테이블idnameprice1후라이드 치킨150002양념 치킨200003고구마 피자300004아보카도 피자50000 두 테이블의 관계를 보자. 예를 들어, 고객 1명은 음식 N개를 주문 할 수 있다. 라고 가정한다면, 고객 : 음식 = 1 : N 관계라고 ..

프로젝트 MVP 개발을 먼저 끝내고 본격적으로 리팩토링 작업에 들어갔다. 그러다가 무식하게 반복문으로 업데이트를 날리는 로직을 발견하였고, 이를 기점으로 쿼리 튜닝이 필요하다고 판단하였다. 이번에는 벌크 연산에 대해서 이야기 하려고 한다. 문제점기존 코드는 아래와 같이soft-delete 처리를 해준 후,반복문으로 업데이트 처리를 해주고 있었다. (쿼리가 여러개 날라가서 비효율적이다)//특정 게시글의 전체 댓글 삭제public void deleteComments(String postId, String userId){ List comments = commentRepository.findCommentAll(postId); if(comments.isEmpty()){ throw new Ba..

1차적으로 프로젝트 MVP 개발을 마무리하고, 리팩토링 작업에 들어갔다. 작성했던 코드를 다시한번 살펴보는데 머리가 아파오기 시작했다. 짧은 기간동안 MVP 개발에만 집중했던 탓인지 가독성이 떨어지고, 중복되는 코드가 많고, 네이밍 규칙도 존재하지 않는 등 많은 문제가 보이는 내 코드들을 보니 마음이 아파왔다. 그래서 코드의 효율성과 가독성을 위해서 리팩토링을 하기로 마음먹었다. 문제점 발견 코드를 보다보니 내 눈에 들어온 것은 미래를 생각하지 않은 if문 사용이었다. //댓글 달기 public void commentService(CommentRequestDTO commentRequestDTO, CustomUserDetails customUserDetails){ String postId = c..

싱글톤 패턴은, 하나의 클래스에 오직 하나의 인스턴스만 가지는 패턴이다. 보통 하나의 클래스를 가지고 여러개의 인스턴스를 만들 수 있지만,그렇게 하지 않고, 하나의 인스턴스만 만드는 것이다!보통 데이터베이스 연결 모듈에 많이 사용한다. 이렇게 한다면, 장점하나의 인스턴스를 다른 모듈들이 공유하며 사용하기 때문에 새로운 인스턴스를 생성하는 비용이 줄어든다.단점하나의 인스턴스를 다른 모듈들이 공유하면 사용하기 때문에 해당 인스턴스의 의존성이 높아진다. // DB 연결을 하는 것이기 때문에 비용이 더 높은 작업 const URL = 'mongodb://localhost:27017/kundolapp' const createConnection = url => ({"url" : url}) class ..

이번 프로젝트를 진행하면서댓글 기능을 개발하게 되어서  어떻게 개발을 하게되었는지 이야기 해보려고 한다. 댓글은 위 이미지처럼 개발할 예정이다  댓글하나에 대댓글 작성이 가능하고대댓글의 대댓글은 작성 불가능하도록 할 것이다.   테이블 설계 댓글 테이블은 아래와 같이 구성할 예정이다.   MSA 기반 프로젝트이기 때문에 댓글과 연관관계를 가져야 될 서비스들은 분리 되어 있다.그리고 서비스의 특성상 어떤 모임의 댓글인지를 구분해줄 모임 id가 존재한다. 컬럼들을 설명해보자면, comment_class : 댓글 종류를 구분해주는 역할을 해준다. 0은 댓글, 1은 대댓글임을 표시해주는 역할을 한다parent_id : 만약 대댓글인 경우 댓글(부모댓글)의 id를 넣어줘서 어떤 댓글의 대댓글인지를 알려주는 역할을..