TIL DAY 9 || Starbucks Product Page Modeling Review

TK·2021년 2월 25일
0

TIL

목록 보기
12/55

Before Review

다음은 우리 팀이 진행한 스타벅스 프로덕트 페이지 모델링을 AqeuryTool 로 구현한 것이다.

먼저 우리가 모델링 해야했던 구현 요소들은 다음과 같았다.

필수 구현요소 : 음료, 카테고리, 영양 정보, 알러지, 음료 이미지, 음료 설명, 신상 여부

그래서 처음엔 음료가 중심 테이블이 되어서 여러 테이블과 유기적으로 합치려고 했다.

  • drinks_info 에는 먼저 description, new, image 컬럼을 추가했다. 이 때는 리뷰를 받기 전이라서 상품 당 image 가 하나밖에 없다고 생각해서 같은 테이블내에 추가했다.

  • 먼저 one-to-many 관계로 drinks_info 테이블과 categories 테이블을 연결했다. drinks_info - N : categories - 1 이기 때문에 N -> 1 쪽으로 foreign key 를 연결해줬다.

  • allergic_info 테이블은, 알러지 정보가 많기 때문에 따로 관리하기 위해 추가했다. 값은 그렇거나/그렇지않거나 이기 때문에 ENUM(T/F) 타입으로 정해줬다. 스타벅스 알러지 종류라고 구글링을 해서 나온 자료들을 바탕으로 16가지의 알러지 컬럼을 추가했다. 이 때 알러지 종류들은 이미 있는 것이기에 새로 추가되지 않을 것이라고 판단했기 때문이다. 하지만 나중에 리뷰를 받고 생각이 달라졌다.

  • 방금 설명한 allergic_info 테이블과 drinks_info 테이블을 one-to-one 관계로 연결했다. 관계가 row 하나당 다른 테이블 row 하나였기 때문이다. 이 때 방향은 allergic_info 가 drinks_info 를 참조했다.

  • nutrition_info 테이블은 영양정보를 나눠서 관리하기 위함이였다. 역시 drinks_info 테이블과 one-to-one 관계로 연결했다. 이 때 방향은 nutrition_info 가 drinks_info 를 참조했다.

여기까지는 팀원들과 논의한 내용을 바탕으로 ERM 을 작성한 것이다. 다음은 리뷰를 받고 난 뒤 수정사항이다.

After Review

Data Type & naming convention

리뷰를 받고 먼저 우리가 만든 것 보다 훨씬 더 개선할 수 있겠다 라는 생각이 들었다. 먼저 naming convention 과 자료 타입에 관한 것이다.

  • naming convention 에 관련하여 Table name 은 small letter & plural 을 사용한다.
  • foreign key 는 <참조할 테이블>_id 로 표기한다.
  • boolean type (0 or 1) 을 처리할 땐 ENUM 도 가능하지만 보통 TINYINT 을 사용

Table Relations

테이블 간 fk 로 연결하는 것에 관한 리뷰인데 피가되고 살이되는 피드백이였다. 먼저 우리팀이 했던 치명적인 실수에 대해서 알아보자.

  • (drinks <- allergic_info) 를 one-to-one 으로 연결했었다. 하지만 이렇게 했을 때 다음과 같은 문제점이 있다.
  1. 예를들어 스타벅스에서 오징어 블렌디드를 출시했다고 가정해보자. 그러면 allergic_info 테이블에 새로운 컬럼을 추가해야한다. 그런데 이미 추가했던 이전 row 에 새로 생긴 오징어 컬럼을 다 추가해줘야 하기 때문에 memory cost 가 많이 든다.

  2. 보통 한 음료당 알러지가 한 두개 이기 때문에, 예를들어 우유, 대두만 있으면 나머지 알러지 컬럼은 쓸데없이 전부 false 로 채워야 되는 불편함이 있다. 혹은 모든 컬럼이 전부 false 가 될 수도 있다. 이런 경우에는 그 row 자체가 필요 없다.

--> 그렇기 때문에 many_to_many 로, allergy 테이블과 drinks 테이블을 잇는 테이블 allergy_drink 를 만든다. 새로운 알러지를 가진 상품이 추가되더라도 allergy 테이블에 새로운 알러지 컬럼 자체가 아니라 알러지 name 컬럼 값으로 들어가기 때문에, 기존의 컬럼에 영향을 주지 않는다.

  • image 는 여러개일 수 있다는 사실을 알았다. 따라서 images 테이블을 만들어서 drinks 테이블과 one-to-many 관계로 연결했다. 방향은 images 테이블이 drinks 를 참조하도록 했다.

Tips

one-to-one, one-to-many, many-to-many 의 개념이 모두 헷갈리는 개념이였다.

하지만 쉽게 생각할 수 있는 팁 몇가지를 소개한다.

  • one-to-one
  1. 한 테이블에서 다른 테이블의 한 row 로만 간다. 여러 row 로 가면 안된다.
  2. 보통 세부적 내용이 있는 하위 테이블에서 상위 테이블을 참조한다. eg) nutritions -> drinks
  • one-to-many
  1. 두개의 테이블을 봤을 때 둘 중 하나가 다른 테이블의 여러 row 로 간다. 꼭 둘 중 하나의 테이블만 이래야한다.
  2. N : 1 의 관계에서 항상 N 이 1 쪽의 테이블을 참조한다.
  • many-to-many
  1. 서로의 테이블이 여러 row 를 참조한다. 이건 꼭 양방향으로 서로 다른 테이블의 여러 row 를 참조해야 성립한다.
  2. 서로 두개의 테이블이 직접 연결은 불가능하기 때문에 두 테이블을 잇는 새로운 테이블을 만든다.
  3. 참조하는 방향은 새로운 테이블에서 각자의 테이블로 해야한다.
  4. 새로운 테이블과 각자의 테이블의 관계는 항상 1 : N(새 테이블) 이어야 한다.

아주 좋은 리뷰시간이었다.

profile
Backend Developer

0개의 댓글