JPA를 사용하는 프로젝트를 진행하면서 다대다 관계를 풀어내야할 일이 생겼다. 객체 지향언어에서는 2개의 컬렉션 객체로 다대다 관계를 표현 할 수 있지만, 관계형 데이터베이스는 정규화된 2개의 테이블로 다대다 관계를 표현할 수 없다. 이와 같은 한계를 극복하기 위해 중간 테이블을 Entity로 만들어, 일대다 - 다대일 관계로 풀어내야한다. 프로젝트에서 정의한 도메인 관계는 다음과 같다. (관계형 데이터베이스에서 다대다 관계는 없다.) RECRUITMENT : 모집글 테이블 CATEGORY : 카테고리 (태그) 테이블 하나의 모집글은 여러개의 카테고리 (태그)를 가질 수 있고 하나의 카테고리는 여러 모집글에 할당될 수 있기 때문에 다대다 관계이다. 이를 관계형 데이터베이스에서 풀어내려면 중간 테이블을 생..
프로젝트에서 중요한 도메인에는 상대적으로 많은 데이터가 필요하다. 이러한 데이터들 중 등록일, 수정일과 같은 날짜에 관련된 값은 많은 도메인에서 공통적으로 필요한 컬럼이다. 다음의 예제를 보자. 위 3개의 테이블에서는 CREATED_DATE (등록일), MODIFIED_DATE (수정일) 컬럼을 공통적으로 가지고 있다. 이렇게 날짜와 관련된 값들은 일일이 관리하기에 매우 귀찮을 수 있다. 등록일 같은 경우엔 그나마 데이터를 저장하기 전에 한 번만 값을 넣어주면 되지만, 수정일은 데이터를 변경할 때마다 모든 set 이나 update 메서드에 수정 시간을 변경하는 코드를 작성해야한다. JPA에서는 이러한 문제점을 해결하기 위해 Auditing 이라는 기능을 지원한다. Auditing 의 사전적 정의는 '감사..
최근 개인 프로젝트에서 api를 만들던 중, 연관 관계를 가진 엔티티를 저장해야할 일이 생겼다. 사실, DB 테이블에는 연관 관계라는 것이 없고 해당 테이블의 FK(ID 값)만 맞춰주면 되는데 JPA가 패러다임의 차이를 극복해주기 때문에 Entity라는 객체를 필드에 저장하도록 설계되어있다. 따라서, 엔티티를 저장할 때 연관 관계를 나타내는 필드들도 객체로 채워주어야 한다. 문제 상황 다음은 ANSWER 테이블을 나타내는 Entity이다. @Getter @NoArgsConstructor @Entity public class Answer { @Column(name = "ANSWER_ID") @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private L..
