study20 JPA Indexing은 개념에 맞게 사용해 중복을 피하자 JPA에서는 DB Indexing기능을 아주 간단하게 제공해준다. 혹시 DB Indexing에 대해 잘 모른다면 해당 영상을 참고하도록 하자. 한 줄로 요약하자면, 데이터가 수억개 있을 때, 특정 값을 검색하기 편하게 트리 형태로 인덱스 칼럼을 따로 저장해서 검색을 좀 더 빠르고 간결하게 하겠다는 것이다. 조금 깊이 알고 싶으면 해당 영상을 참고하면 좋다. 예를 들어, 1억 개의 데이터가 있는데 이 중에 id = 3524125인 값을 SELECT해주세요. 하면 1억 개를 전부 뒤져야한다. 그러나 인덱스에 해당 칼럼을 저장해놓으면 업다운 게임처럼 트리를 이용해서 훨씬 빠른 시간에 찾을 수 있다. 특히 관계형 DB를 사용해 데이터를 영속화하는 경우에는 하나의 테이블에 꽤 많은 데이터가 저장되기 때문에, 인덱.. 2024. 4. 15. 중간 테이블은 어느 도메인에 위치시켜야할까? 데이터베이스 설계를 하다보면 종종 다대다 관계를 마주한다. 그리고 다대다 관계를 해결하기 위해 중간 테이블을 사용하는 것이 일반적이다. 다대다 테이블을 사용하면, @ManyToMany와 @JoinTable을 사용하는 것보다 유연하게 테이블 및 소프트웨어 디자인이 가능하다. 중간 테이블에 더 많은 정보를 담을 수 있다. @JoinTable에는 양쪽 테이블의 id값밖에 담지 못한다. 추가 칼럼을 담을 수 있다는 것은 곧 해당 테이블이 새로운 개념으로 확장될 수 있다는 의미다. 그런데, 그럼 중간 테이블은 어디에 두는 것이 옳을까? 예를 들어, A라는 도메인과 B라는 도메인의 중간 테이블인 C엔티티는 어느 도메인 패키지에 두는 것이 옳을까. 내가 생각한 방안은 크게 두 가지였다. A 또는 B 도메인의 하위 .. 2024. 3. 26. 바버 - 바버샵 최종장 : 중간 테이블... 써야겠지? 회원과 바버샵 간의 연관관계를 다루는 (아마) 최종 게시글이다. 결국 중간에 테이블을 하나 사용하기로 했다. 그렇다고 조인해서 정보를 사용하는 경우는 아마 없을 것 같긴하다. 일대다의 방향성을 지닌 연관관계를 사용하지 않고자 최대한 노력하고있고, 그럼 굳이 테이블을 조인해서 어떤 정보를 찾아올 이유도 없다. 게시글을 조회하면 댓글 리스트에 대한 조회 요청이 같이 오는 것과 마찬가지로, 바버샵을 조회하면 해당 조인 테이블에 대한 조회 요청도 같이 보낸다. 이렇게 엔티티 간 연관을 끊고 id에 의한 약한 연관관계를 유지하면서, 좀 더 상위 도메인을 방어적으로 다룰 수 있다. 아무튼 처음의 생각으로 돌아가보자. 처음 생각했던 테이블 설계는 아래 그림과 같았다. Member도메인 자체를 두 개의 도메인으로 분리.. 2024. 3. 3. 롤백 - 회원을 왜 나눠 아주 바보같은 생각이었다. 회원이 바버샵과 연관이 있다고 회원을 나눈다니. 이번 프로젝트 설계의 가장 근간은 회원은 절대 지킨다였다. 그런데, 회원이 바버샵과 연관이 있다고 회원 도메인에 바버샵 도메인을 침투시킨다? 무슨 이런 바보같은... 회원과 바버샵이 연관되어 있으면, 회원이 바버샵에 의존하는게 아니라 바버샵이 회원에 의존하는게 맞다. 이런 기본 원칙을 까먹고 멍청하게 프로젝트를 진행하고 있었다.... 이전에 생각했던 바버와 바버샵 클래스를 코드로 표현하면 아래와 같다. class Barber { ... private final BarberShop workPlace; ... } ////////////////////////////// class BarberShop { ... private final .. 2024. 2. 28. 구체 클래스 vs 추상 클래스 vs 인터페이스 - 고객 / 바버 추상화하기 이전 글에서 현재 사용 중인 회원 도메인을 고객과 바버의 두 개의 도메인으로 분리하기로 했다. 고객은 바버샵과 연관관계를 맺지 않아도 되지만, 리뷰에 답글을 달거나 바버샵과 관련한 기능들을 수행하기 위해서 바버는 바버샵과 연관을 맺어야하기 때문이다. 한 가지 고민해 볼 점은 고객과 바버를 완전히 다른 도메인으로 분리하느냐, 엔티티 레벨에서만 분리하고 하나의 도메인(회원)에서 사용하느냐이다. 물론 둘을 완벽하게 분리해서 사용하는 것은 충분히 가능하다. 애초에 회원가입을 시도할 때, 해당 사용자의 직군을 기준으로 서버 쪽에 요청을 다르게 날리면 된다. 이후에는 클라이언트에 회원의 정보를 쏴줄 때마다 해당 사용자의 역할을 담아 보내고, 그에 맞게 클라이언트에서 다시 요청을 보내면 된다. 이전 글에서는 클라이언.. 2024. 2. 27. 이전 1 2 3 4 다음 반응형
