1. 문제 인식

초기 데이터베이스 설계 단계에서는 다음과 같은 문제를 인식하였습니다.

• 한 식당이 라벨을 여러개 가질수 있다.

  초기에는 restaurants 테이블에 라벨을 VARCHAR 형식으로 저장하였습니다. 하지만 한 식당이 라벨을 여러개 가질 수 있고, 라벨이라는 데이터는 검색이나 마커를 불러오는 중요한 역할을 하기 때문에 식당이 라벨의 값을 “한식, 국밥” 가진다고 하면, 라벨을 저장하거나 쿼리문을 통해 사용할 때 불편함을 야기할 수 있습니다.

• 대표 사진 설정의 중복 문제

  초기에는 restaurants 라는 테이블에 식당 정보 조회시 사용할 대표 사진을 저장하려고 하였습니다. 하지만 만약 메뉴 사진과 대표 사진이 겹치거나, 메뉴 사진을 별도의 테이블 없이 직접 식당 정보에 포함하면, 중복된 사진 데이터를 불필요하게 저장하게 될 가능성이 있었기 때문에 정규화적인 관점에서 어긋났습니다.

2. 해결 과정

• 라벨 데이터 별도 관리
  • labels 테이블을 생성하여 모든 라벨을 유일한 ID로 관리하도록 설계했습니다.
  • 라벨과 식당 간의 관계를 관리하기 위해 다대다 관계를 구현, restaurant_labels 테이블을 생성했습니다.
  • 이를 통해 라벨 데이터를 재사용하고, 라벨 데이터를 용이하게 관리할 수 있었습니다.
• 사진 데이터 중복 방지
  • 메뉴 정보를 menus 테이블에 저장하고, 각 메뉴에 대한 사진(photo_url)을 1대1 관계로 관리하도록 설계했습니다.
  • 대표 사진은 메뉴 테이블에서 사진을 불러들여서 사용하도록 하였습니다.

3. 적용한 설계

1. labels 테이블과 restaurant_labels 테이블 설계
   • labels 테이블에 라벨 이름을 저장합니다.
   • restaurant_labels 테이블을 통해 restaurants와 labels를 연결합니다.

labels (라벨)
+----+----------+
| id | name     |
+----+----------+
| 1  | 한식      |
| 2  | 양식      |
| 3  | 중식      |
+----+----------+

restaurant_labels (식당-라벨 연결)
+----+--------------+---------+
| id | restaurant_id| label_id|
+----+--------------+---------+
| 1  | 1            | 1       |
| 2  | 2            | 2       |
| 3  | 1            | 3       |
+----+--------------+---------+

1. menus 테이블에서 대표 사진 선택
   • menus 테이블에 각 메뉴 사진을 저장합니다.

menus (메뉴)
+----+--------------+---------+----------------------+
| id | restaurant_id| name    | photo_url            |
+----+--------------+---------+----------------------+
| 1  | 1            | 김치찌개  |   photo_link_1       |
| 2  | 1            | 된장찌개  |   photo_link_2       |
| 3  | 2            | 스테이크  |   photo_link_3       |
+----+--------------+---------+----------------------+

4. 결과

• 데이터 중복 방지: 라벨과 메뉴 데이터를 별도의 테이블로 관리하여 다수의 데이터를 중복을 방지하고 용이하게 관리할 수 있습니다.
• 확장성 증가: 새로운 라벨 추가 및 식당-라벨 연결 관리가 간단해집니다.
• 쿼리 효율성: 메뉴 사진을 1대1로 관리하여 대표 사진 선택 쿼리가 간결하고 효율적으로 처리 가능합니다.
• 유지보수성 향상: 데이터베이스 구조가 명확해져 추가 요구사항 대응이 쉬워집니다.

5. 느낀 점

• 데이터베이스를 설계하면서 데이터 중복 방지를 위해 정규화된 테이블 설계가 중요하다는 걸 배웠습니다.
• 다대다 관계 테이블을 활용하면 데이터 관계를 유연하고 확장성 있게 관리할 수 있으며, 항상 확장성을 생각하며 데이터베이스를 설계 해야하는것을 배웠으며, 초기 설계 단계에서 많이 고민하여 테이블 구조를 잡는 것이 효율적임을 배웠습니다.