Naweke - 1차 프로젝트 전체 회고 - 2. DB Modeling

[이전글]

1. Naweke - 1차 프로젝트 전체 회고 - 1. 기획

 

2. 데이터베이스 모델링

DB 모델링도 결국 WHAT, WHY, HOW!

기획을 마치고 프론트엔드 파트는 화면 레이아웃을 만들기 시작했고, 백앤드는 Database modeling을 시작했다.

user로부터 받아야 하는 데이터, user에게 제공해야 하는 서비스와 관련된 데이터 테이블들을 정규화하고 각 테이블의 관계를 이어가는 작업은 처음 하는 우리에게 쉽지는 않았다.

 

왜 쉽지 않았을까? 단순히 처음해보아서가 아니라, 서비스의 로직에 대한 이해도가 낮았기 때문에 그 로직에 따라 어떤 스키마를 만들어야하고 어떤 data column으로 해당 스키마를 만들어야 하는지 생각하는 것이 어려웠던 것이라고 생각한다.

 

특히나 그때 우리는 특정 "기능"을 중심으로 스키마를 짜기보다 부분적으로 "유저 테이블이 필요하겠지? 구매 테이블도 필요하지 않을까요?" 라고 산발적으로 생각하면서 테이블을 정의했었다.

 

그렇게 스키마를 설계하다보니 맞이한 문제는, 서비스 로직 상 있어야 하는 스키마가 없던 것이 가장 큰 문제였다. 구매 테이블은 있지만 카트, 주문테이블이 없었고 주문건의 상태와 주문 상품들의 배송현황 등을 다루는 상태 테이블 등이 없는 등 기능 구현에 필수적인 테이블이 부분부분 빠져있었다.

 

그래서 다음 프로젝트 부터는 어떤 기능을 구현할지 정의했다면, 스키마를 짜기 전에 해당 기능이 구현되는 과정을 DB 중심으로 구조를 잡아본 후 스키마 작성을 해야겠다는 생각이 들었다.

 

그리고 또 DB 모델링을 하면서 배운 중요한 점이 있다.

1. DB 입장에서 유저가 사는 상품은 상품 그 자체가 아니라 상품의 옵션이라는 것.

-> 구매 데이터를 단순히 product id로 저장하는 것이 아니라 product_options의 id로 저장해야한다.

2. 고객은 Carts를 사는 것이 아니라 Products를 사는 것.

-> 구매 데이터는 Carts와 별개라는 것. 유저가 카트에 있는 products를 구매하니까 구매 table과 장바구니 table의 관계를 설정해야할 것 같지만, DB 입장에서는 Cart에 담긴 데이터를 구매 테이블과 연결하면, 유저가 cart를 산 것이라는 의미가 된다. 따라서, 구매 테이블은 products_options 테이블과 직접 연결되어야 한다.

 

이외에도 상품 카테고리를 나눌 때 테이블의 확장 가능성을 고려해야한다는 점, 휴먼 에러 방지 등 DB 모델링에 생각보다 많은 것들이 고려되어야 한다는 것을 배울 수 있었다.

 

[다음글]

3. Naweke - 1차 프로젝트 전체 회고 - 3. API 제작 및 배포

4. Naweke - 1차 프로젝트 전체 회고 - 4. 회고