DB로 들여다보는 Sluv의 성장 과정 (2)

DB로 들여다보는 Sluv의 성장 과정 (1)

저번 글에서는 Sluv의 DB를 설계하는 3단계 방법을 소개했습니다.

 

이번글에서는 Sluv DB를 설계하면서 어려웠던 점과 그 부분을 어떻게 해결했는지에 대해 소개해드리겠습니다.

 

Sluv DB를 설계하며 어려웠던 부분은 다음과 같습니다.

1. 기존에 DB에 있는 Brand와 Celeb이 아닌 새로운 Brand나 Celeb을 사용자가 추가하는 경우.
2. 질문하기 커뮤니티의 타입에 따라 저장해야 하는 정보의 종류가 달라 발생하는 문제.

Sluv DB를 설계하면서 어려웠던 점 1

1. 기존에 DB에 있는 Brand와 Celeb이 아닌 새로운 Brand나 Celeb을 사용자가 추가하는 경우.

Sluv의 정보 공유 게시글을 등록할 때는 착용한 Celeb과 어떤 브랜드의 상품인지의 입력은 필수입니다.

 

 

셀럽 선택은 설정한 관심 셀럽, 인기 셀럽, 그리고 검색을 통해 DB에 있는 셀럽을 선택할 수 있는 구조입니다.

 

브랜드 선택 또한 인기 셀럽, 그리고 검색을 통해 DB에 있는 셀럽을 선택할 수 있는 구조입니다.

 

 

하지만 문제는 여기서 발생합니다.

사용자가 선택하고 싶은 셀럽이나 브랜드가 DB에 없다면 선택할 수 없다는 문제가 있습니다.

 

 

어려웠던 점 해결 1

이러한 문제를 해결하기 위해서 NewCeleb과 NewBrand를 도입했습니다.

사용자가 입력한 이름을 바탕으로 NewCeleb 혹은 NewBrand를 만들고, 관리자 페이지에서 관리자가 검토 후에 Celeb 혹은 Brand로 변경하는 방식으로 해결하였습니다.

 

- NewCeleb Entity 추가.

  -> 사용자가 입력한 이름을 바탕으로 생성되는 NewCeleb

- NewBrand Entity 추가.

  -> 사용자가 입력한 이름을 바탕으로 생성되는 NewBrand

- 기존 정보공유 Entity : Celeb, Brand

   -> 수정한 정보공유 Entity : Celeb, Brand, NewCeleb, NewBrand

 

정보 공유에서 해당 아이템을 착용한 Celeb과 아이템의 브랜드의 선택은 필수입니다. 때문에 기존의 정보 공유 Entity는 Celeb과 Brand는 NotNull 상태였습니다.

Celeb과 Brand를 Null 가능으로 변경한 뒤, 정보 공유 Entity에 NewCeleb, New Brand를 추가하여 총 Celeb, Brand, NewCeleb, NewBrand 4개로 관리합니다.

 

- DB에 있는 Celeb, Brand를 선택: Celeb, Brand에 값이 채워지고, NewCeleb, NewBrand는 Null 상태.

- DB에 없는 Celeb, Brand를 선택: NewCeleb, NewBrand에 값이 채워지고, Celeb, Brand는 Null 상태.

 

 

 

Sluv DB를 설계하면서 어려웠던 점 2

2. 질문하기 커뮤니티의 타입에 따라 저장해야 하는 정보의 종류가 달라 발생하는 문제.

질문하기 커뮤니티에는 다양한 종류의 글을 쓸 수 있습니다. 

 

1. 찾아주세요: 특정 셀럽이 착용했던 아이템이 어떤 제품인지 찾아달라는 형태의 글입니다.

2. 질문해요-[이 중에 뭐 살까]: 투표를 받는 형태의 글입니다.

3. 질문해요-[이거 어때]: 무언가를 올리고 다른 유저들의 의견을 받는 형태의 글입니다.

4. 질문해요-[추천해 줘]: 원하는 정보를 다른 유저들에게 추천받는 형태의 글입니다.

 

모두 비슷하지만 분명히 다른 정보를 요구하는 형태들입니다.

 

여기서 문제가 발생합니다.

DB에 종류별로 각각 만든다면 테이블이 너무 많아지고 복잡해지는 문제가 발생했습니다.

 

 

어려웠던 점 해결 2

이 문제를 해결하기 위해서 JPA의 단일 테이블 전략을 사용하였습니다.

@Inheritance(strategy = InheritanceType.SINGLE_TABLE)

 

 

각각의 형태를 JPA Entity로 생성 후 Question Entity를 상속받는 구조로 구현하였고, 단일 테이블 전략을 사용하여 실제 DB에는 1개의 테이블에 모두 들어가게 설정하였습니다.

 

해당 방법을 사용하면, 질문의 형태마다 각각 DB에 테이블이 생기는 것을 막고, JPA 안에서 상속을 이용하기 때문에 관리하기 쉬워집니다.