전체 글 (55) 썸네일형 리스트형 DAY14 - JPA 연관관계 매핑 완전 정리 @ManyToOne, @OneToMany, mappedBy, LAZY까 학습일: 2026-09-20 프로젝트: luxit 주제: JPA 연관관계 매핑, 연관관계의 주인, mappedBy, LAZY 로딩 1. 오늘 학습 목표 관계형 데이터베이스에서는 테이블 간 관계를 FK(Foreign Key)로 표현한다. 예를 들어 입찰 테이블이 특정 경매에 속한다면 bids.auction_id 같은 FK 컬럼을 사용한다. 하지만 Java에서는 단순히 ID 값만 저장하기보다 객체 자체를 참조하는 방식이 더 자연스럽다. private Auction auction; JPA의 연관관계 매핑은 DB의 FK와 Java 객체 참조를 연결한다. Databasebids.auction_id ↓JPA@ManyToOne ↓Java.. Day13 - JPA 기초와 영속성 컨텍스트, Dirty Checking 직접 검증하기 1. 오늘의 학습 목표 오늘은 기존에 메모리에서 관리하던 상품 데이터를 Spring Data JPA와 PostgreSQL을 이용해 실제 데이터베이스에 저장하도록 변경했다. 특히 단순히 JPA 문법을 사용하는 것에 그치지 않고, JPA의 핵심 개념인 Entity, 영속성 컨텍스트, Dirty Checking이 실제 애플리케이션에서 어떻게 동작하는지 직접 확인했다. ORM / JPA / Hibernate 관계 이해 JPA Entity 작성 Spring Data JPA Repository 적용 PostgreSQL 연동 @Transactional 적용 Dirty Checking 직접 검증 JPA 기반 CRUD 검증 2. OR.. DAY12 - PostgreSQL JOIN과 데이터 관계 — INNER/LEFT JOIN부터 GROUP BY, HAVING까지 Day 11에서는 PostgreSQL에 직접 데이터베이스와 테이블을 만들고 기본적인 CRUD와 제약조건을 다뤘다. 오늘은 여기서 한 단계 더 나아가, 서로 다른 테이블에 나뉘어 있는 데이터를 연결해서 조회하는 JOIN을 공부했다. luxit 프로젝트에서는 상품, 경매, 입찰, 사용자가 각각 별도의 데이터이기 때문에 실제 서비스 데이터를 조회하려면 JOIN이 거의 필수적으로 사용된다. 1. 오늘 배운 내용 테이블 관계와 PK / FK INNER JOIN LEFT JOIN 여러 테이블 JOIN WHERE와 JOIN 조합 GROUP BY COUNT, MAX 등의 집계 함수 WHERE와 HAVING의 차이 .. Day11 - PostgreSQL과 SQL, 직접 CRUD부터 제약조건까지 실행해보기 Day 10에서는 관계형 데이터베이스의 기본 개념과 ERD를 설계했다. 이번 Day 11에서는 설계에서 한 단계 더 나아가 PostgreSQL을 직접 설치하고, 실제 데이터베이스와 테이블을 만들어 SQL을 실행해봤다. 지금까지 프로젝트의 Repository는 메모리에 데이터를 저장하고 있었기 때문에 애플리케이션을 종료하면 데이터도 함께 사라졌다. 앞으로 JPA와 실제 데이터베이스를 연결하기 전에, 데이터베이스에서 데이터가 어떤 방식으로 저장되고 조회되는지 직접 확인하는 것이 오늘의 목표였다. 1. PostgreSQL과 SQL PostgreSQL은 관계형 데이터베이스 관리 시스템(RDBMS)이고, SQL은 데이터베이스에 명령을 내릴 때 사용하는 언.. DAY10 - 관계형 데이터베이스와 ERD 설계 정리 - Luxit으로 PK, FK, 관계 이해하기 이번에는 관계형 데이터베이스의 기본 개념을 정리하고, Luxit 프로젝트에서 사용할 데이터 구조를 ERD로 직접 설계해봤다. 지금까지는 Product 데이터를 메모리 Repository에서 관리했지만, 앞으로 PostgreSQL과 JPA를 사용하려면 먼저 어떤 데이터를 어떤 테이블에 저장하고 서로 어떻게 연결할지 정리할 필요가 있다. 단순히 PK, FK 개념만 외우기보다는 실제 Luxit의 User, Product, Auction, Bid 같은 도메인을 기준으로 관계를 만들어보면서 학습했다. 1. 관계형 데이터베이스 관계형 데이터베이스는 데이터를 테이블 형태로 저장하고, 테이블 사이의 관계를 이용해서 데이터를 관리하는 방식이다. .. Day09 - Spring Boot 상품 CRUD 완성하기 - PUT, DELETE와 메모리 Repository 오늘은 상품 API의 CRUD를 완성했다. Day 6부터 HTTP와 Spring MVC를 배우고, Day 7에서 Controller-Service-Repository 구조를 정리한 뒤 Day 8에서는 Validation과 공통 예외 처리를 구현했다. 이번 Day 9에서는 지금까지 만든 구조를 활용해서 상품 수정과 삭제 기능까지 추가했다.아직 데이터베이스를 연결하지 않았기 때문에 상품 데이터는 메모리의 List에 저장하고 있다. 하지만 API의 전체 흐름은 실제 REST API와 동일하게 구성해서 POST, GET, PUT, DELETE 요청을 모두 직접 테스트해봤다.1. CRUD란?CRUD는 데이터를 다룰 때 사용하는 가장 기본적인 네 가지 작업을 의미한다.Create : 데이터 생성Read : 데이터 .. DAY08 - Spring Validation과 공통 예외 처리로 API 오류 응답 정리하기 오늘은 Spring에서 요청값을 검증하는 Validation과 여러 Controller에서 발생하는 예외를 한 곳에서 처리하는 방법을 공부했다. 이전까지는 상품이 존재하지 않을 경우 Controller에서 직접 404 응답을 만들어 반환했는데, 이번에는 예외를 발생시키고 공통 예외 처리기가 HTTP 응답을 만들어주는 구조로 변경했다.Validation은 잘못된 요청값이 Service나 Domain까지 전달되기 전에 차단하는 역할을 한다. 반면 비즈니스 규칙을 위반한 경우에는 Service 또는 Domain에서 예외를 발생시키는 방식으로 구분할 수 있다.Validation이란?Validation은 클라이언트가 보낸 요청 데이터가 우리가 정한 조건을 만족하는지 확인하는 과정이다.예를 들어 상품 등록 요청에서.. DAY07 - Layered Architecture와 계층별 역할 정리 오늘은 Spring Boot에서 많이 사용하는 Layered Architecture 구조에 대해 학습했다.기존에 만들어둔 상품 조회 API를 기준으로 Controller, Service, Repository, Domain, DTO가 각각 어떤 역할을 담당하는지 확인하고,실제 코드가 계층별 책임에 맞게 분리되어 있는지도 점검했다.1. Layered Architecture란?Layered Architecture는 애플리케이션의 역할을 여러 계층으로 나누어 관리하는 구조다.각 계층이 담당하는 역할을 분리하면 코드의 책임이 명확해지고, 이후 기능이 추가되거나 변경될 때 유지보수가 쉬워진다.Client ↓Controller ↓Service ↓Repository ↓Domain이번 프로젝트에서는 상품 조회 기.. 이전 1 2 3 4 ··· 7 다음