[이슈 #1] 고객의 주문 내역을 조회할 때 테이블 다수 조인 이슈

위 프로젝트에 대한 소개는 다음 URL에서 확인할 수 있습니다.

ERD와 Github 등의 URL이 포함되어있습니다.

https://deveric.tistory.com/58

[DelFood] 프로젝트 소개

 

 

데이터 베이스 설계 도중 고객이 주문한 주문 내역을 조회하려면 테이블이 다수 조인되는 것을 확인하였습니다.

 

주문내역 조회시 조인되는 테이블은 다음과 같습니다.

 

 

주문 - 주문 메뉴 - 주문메뉴 옵션 - 메뉴 옵션 - 메뉴옵션 카테고리 - 메뉴 - 고객 - 주문 주소

총 8개의 테이블이 조인되어야 조회가 가능한 상황이라서 성능적인 부분에 대한 문제가 걱정됩니다.

 

테이블이 이렇게 많이 나뉜 이유는 다음과 같습니다.

고객과 주문주소 테이블의 분리 이유

주문 주소테이블과 고객 테이블을 분리한 이유는 주문 주소를 객체로 만들어 고객이 이전에 주문한 주소들을 저장해 두었다가 다시 예전 주소를 고를 수 있도록 1:N 관계를 위해서 분리해 둔 것 입니다.

 

 

메뉴 - 메뉴 옵션 - 메뉴옵션 카테고리의 분리 이유

메뉴에 추가적인 옵션을 고를 수 있도록 한 것입니다. 여러개의 옵션을 선택할 수 있도록 1:N 관계를 만들어두었습니다.

예를 들어 치킨을 주문하는 상황을 들 수 있습니다.

 

후라이드 치킨 메뉴를 선택한 후 추가 가능한 옵션은

1. 치즈 시즈닝 추가(500원) 2, 양파 시즈닝 추가(500원), 3. 양 200g 추가(3000원)... 와 같은 옵션입니다.

 

위 옵션들은 이렇게도 묶을 수 있습니다.

 

---

후라이드 치킨 - 17,000원

Category - 시즈닝

1. 치즈 시즈닝 추가 (500원)

2. 양파 시즈닝 추가 (500원)

Category - 곱빼기

양 200g 추가 (3000원)

---

 

 

Category는 메뉴옵션 카테고리가 되는 것이고, 메뉴 옵션은 하위 메뉴들이 됩니다. 위와 같은 옵션들은 한번에 여러가지를 선택할 수 있게 만들어 두기 위해 1:N 맵핑을 선택하였습니다.

 

 

역 정규화 고려

위와 같이 다수의 테이블이 한번에 조인될 경우 데이터가 많을 때 심각한 성능 저하가 올 수 있다고 생각합니다.

그렇기 때문에 꼭 필요한 기능이 아닌 테이블을 역정규화하여 조인 테이블을 줄이고자 하였습니다.

 

역정규화의 대상으로 선택한 테이블 관계는 고객-주문 주소입니다.

고객 테이블에 주소 컬럼을 추가하여 주문 주소 테이블을 제거하려고 합니다.

 

이런 방식으로 역정규화를 진행할 시 고객은 직전에 주문한 주소를 조회할 때 이전에 주문한 테이블에서 조회할 수 있을 것입니다.

 

역정규화를 진행한 결과는 다음과 같습니다.

 

Before

고객 - 주문 주소

 

주문주소 - 주문

 

 

 

 

After - 주문 주소 테이블 삭제

 

 

위와 같이 수정하여 조인할 테이블을 감소시켰습니다. 하지만 아직도 조인해야할 테이블이 많고, 성능 이슈를 어떻게 해결할지 고민해야할 것 같습니다.