sagecode 님의 블로그

복합 키를 쓰면 정말 쿼리 성능이 좋아질까?JPA에서 N:M 관계를 설계할 때, 중간 테이블에 고유 ID(@Id)를 쓸지, 복합 키(@EmbeddedId)를 쓸지는 꽤 자주 마주치는 고민이다.이전 포스팅(복합 키를 사용할 때 주의할 점)에서는 주로 설계적인 장점을 다뤘다면, 이번엔 성능을 실제로 수치화해서 비교해봤다. 실험 배경EduClass에서 ProblemSet(문제집)과 Problem(문제)은 N:M 관계를 갖는다. 이를 위해 중간 테이블 problem_set_to_problem을 설계했는데, 초기엔 단순하게 id를 기본 키로 쓰는 방식으로 구성했다. 하지만 두 가지 문제가 발생했다:중복 등록 방지 불가→ 동일한 문제집-문제 조합이 여러 번 삽입됨조회 성능 저하→ problem_set_id로 검색 ..

학생이 제출한 답안을 채점하는 기존 방식의 문제점 // 학생 시험 채점 @Transactional public void markStudentTest(Long id, StudentTestMarkRequest request) { StudentTest studentTest = getStudentTestById(id); ProblemSet problemSet = studentTest.getProblemSet(); int score = 0; List answerSet = new ArrayList(); // 해답 problemSet.getProblems().forEach(problem -> answerSet.add(problem.getA..

복합키(Composite Key) vs 고유 Id JPA에서 N:M 관계를 매핑할 때, 중간 테이블(연결 테이블)에 고유 ID(@Id)를 넣을 것인지, 복합 키(@EmbeddedId)를 사용할 것인지 고민하는 경우가 많다. 처음에는 "그냥 @Id를 넣고 auto_increment 하면 되지 않나?"라고 생각할 수 있지만, 이 방식은 데이터 무결성과 성능 문제를 초래할 수 있다.본 글에서는 복합 키(Composite Key)를 사용할 때의 장점과 @Id 방식이 가지는 문제점을 분석해보겠다. N:M 관계에서 중간 테이블의 역할ProblemSet(문제지)와 Problem(문제)은 N:M 관계이다.따라서 ProblemSetToProblem이라는 중간 테이블이 필요하다.이때, 이 테이블의 고유 식별자(PK)를 어..

기존 설계에서 Test 엔티티의 역할초기 설계에서는 Test 엔티티가 존재하여 StudentTest 및 ProblemSet과 연관을 맺고 있었다.원래 설계 자체가 Test 엔티티를 먼저 생성을 한 후 Student 엔티티와 N:M 관계를 맺기위해 StudentTest 엔티티를 만들었다.Test 엔티티의 주요 역할은 다음과 같습니다:시험의 개념적 관리: 특정 시험을 식별하고, 관련된 문제(problem set)를 그룹화하는 역할학생과 문제의 연결 고리: StudentTest와 ProblemSet이 Test를 참조하여 시험을 진행시험 단위의 개념적 유지: 시험이라는 개념을 독립적인 엔티티로 유지하여, 여러 학생이 동일한 시험에 응시할 수 있도록 구성Test Entity@Entity@Table(name = "..

@GetMapping 사용법@GetMapping("/api/problem-set/{id}")public ResponseEntity getProblemSet(@PathVariable Long id) { ProblemSet problemSet = problemSetService.getProblemSet(id); // 서비스에서 문제지 조회 return ResponseEntity.ok(new ProblemSetResponse(problemSet));}동작 방식GET /api/problem-set/1 이런 요청이 들어오면{id}에 1이 들어감@PathVariable Long id가 1을 받음problemSetService.getProblemSet(1)이 실행됨@RequestParam과 차이점은?@Pa..

엔터티의 구조를 바꿨다. 일단 user의 타입을 따로 인가테이블에서 관리할 수 있도록 만들었다. 로그인 시 타입에 따라서 다른 테이블에 있는 데이터에 접근할 수 있다. 학생과 학부모의 관계가 n:m 관계이므로, 중간에 연결할 수 있는 학생-학부모 테이블을 생성하였다.관리자 테이블의 속성을 많이 줄였다.이제부터는 이 Entity들을 코드로 변환하기 위한 spring project 구조에 대해서 알아보자. MVC 패턴MVC 패턴은 Spring 프로젝트를 구성할 때, 역할에 따라서 Model, Controller, View로 로직을 분리하여 사용하는 패턴이다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있으며, 좀 더 나은 관리를 하기 위해 사용한다.일단 각각을 알아보기 전에 소프트웨어가 이..

프로젝트 이름은 EduClass로 붙였다.일단 이 서비스 자체가 대학생들이 사용하는 온라인 클래스와 비슷해서 그렇게 부르게 되었다. EduClass를 시작할 데이터베이스를 정리했다. 처음에는 Entity를 구성할 때 좀 막막했던 것 같다. 일단 pk, fk의 개념이 확실히 와닿지 않다보니 중복해서 넣는 속성들이 많아지니 복잡해졌다. 예를 들어보자.처음에는 user의 분류를 3개로 나눴다. '학생', '학부모', '관리자''학생'은 강의를 듣고 시험을 보는 user.'학부모'는 본인의 학생의 강의 수강 상황과 시험 점수를 열람할 수 있는 user'관리자'는 학생과 학부모의 정보를 관리하고 문제와 강의를 편집할 수 있는 user 각각의 email과 pw를 속성으로 만들었다. 그럴 경우 로그인을 할 때 ema..

예전에 부트캠프에서 spring으로 CRUD를 구현해 본 경험이 있다. 그 때는 팀 프로젝트로 진행을 하기도 했고, 학원에서 주는 템플릿으로 디렉토리, 서버, 플로우차트 등 제작을 하였어서 내가 코드를 작성하는 이유를 잘 모르는 상태로 프로젝트를 진행했었다. 그래서 처음으로 개인 프로젝트를 시작하게 되면서 내가 어떤 방법으로 하나의 프로덕트를 만들기 위해서 공부할 과정을 적어보려고 한다.📍 주제 선정나는 처음에 프로젝트 주제를 생각하다 예전에 내가 다닌 대학교 온라인캠퍼스 홈페이지를 클론코딩했던 경험이 있다. 그 땐, 프론트엔드로 개발공부를 하던 시절이라 html, css, js 정도로 구현을 하였다. 근데 그 페이지를 만드는 과정에서 나중에 백엔드를 공부하여 데이터가 움직이고 기능을 구현하는 것까지 ..