Day 104 - 플러스 프로젝트 3단계 중, 더 나은 통합 검색 기능이 되려면 어떤 데이터베이스 구조가 좋을까?

1. 프로젝트 진행 상황 및 계획

🥇 Baro5Nda(바로온다) 프로젝트의 통합 검색 기능 리팩토링하기 (진행 중, 2025.01.21 완료 목표)
🥈 'Request Body vs Request Param vs Path Variable' 특강 준비하기 (진행 전, 2025.01.19 완료 목표) 

🥉 도전 과제 1단계 끝내기 (진행 중, 2025.01.22 완료 목표)
4️⃣ 'AWS의 모든 것(All about AWS)' 강의 모두 듣기 (진행 중, 2025.01.20 완료 목표) 

5️⃣ '자주 사용하는 메서드(method) 및 변수 이름 잘 짓기' 특강 준비하기 (진행 전, 2025.01.20 완료 목표)

 

2. 더 나은 통합 검색 기능이 되려면 어떤 데이터베이스(database) 구조가 좋을까?

(1) 카테고리 개수에 맞추어 열을 분리하여 저장하는 방식 ▼

(2) 하나의 열에 쉼표 같은 구분자로 저장하는 방식 ▼

(3) 별도의 행으로 저장하는 방식 ▼  

(4) 중간 테이블을 사용하여 다대다 관계를 설정하는 방식 ▼

어제 TIL에도 적었다시피 원래는 1번 방식처럼 데이터베이스 구조를 짰는데, 이렇게 하면 카테고리 개수가 바뀔 때마다 비즈니스 로직을 사실상 전부 다 고쳐야 한다는 문제가 있었다. 이런 이유로 데이터베이스 구조를 다시 설계했고, 고민 끝에 4번 방식을 따르기로 했다.

 

2번 방식을 따르자니 카테고리 개별값에 접근하거나 수정하려면 문자열을 분리해야 하는 단점이 있었다. 예를 들어, '야식, 치킨, 튀김'에서 '치킨'만 추출하려면 쉼표를 기준으로 문자열을 나누는 작업이 추가로 필요했다. 정규화가 제대로 이루어지지 않는다는 점도 마음에 걸렸다.

 

3번 방식은 카테고리만 다르고 나머지 값은 모두 동일한 가게가 여러 개 저장되니 불필요하게 저장 공간을 낭비한다는 점이 신경 쓰였다. 가게용 카테고리가 3개라면, 가게가 10개일 때 데이터베이스에 저장되는 행은 30개가 되었다.

 

4번 방식은 카테고리로 가게를 조회할 때 JOIN이 필요해서 성능 저하가 발생할 수 있고, 테이블 구조가 복잡해진다는 단점이 있었으나, 2번이나 3번 방식과 달리 정규화가 제대로 이루어졌고, 데이터 중복을 피할 수 있다는 점이 단점을 뛰어넘는 큰 장점으로 다가왔다.

만약에 서비스 기획이 바뀌어서 기존에 메뉴 정보를 저장한 가게용 카테고리뿐만 아니라 '특별 할인', '예약 가능', '24시간 운영' 같은 가게의 특징도 카테고리로 관리해야 한다면 뭐가 좋을지도 같이 고민했다. ERD(Entity Relationship Diagram)에서도 나타났듯 중간 테이블이 있으면 기존 로직은 거의 건드리지 않고 가게 특징 카테고리를 추가할 수 있었다. 반대로 원래 방식을 유지하면 테이블의 열은 물론이고 기존 로직을 거의 전부 다 손봐야 했다. 정말 쉽진 않겠지만, 더 나은 통합 검색 기능을 구현하고 싶은 만큼 머릿속에 그려본 대로 리팩토링을 쭉 진행할 예정이다. 내일은 오늘보다 더 집중해서 가게용 카테고리로 가게 목록을 검색하는 기능 구현은 끝낼 수 있도록 해야겠다.