다음은 우리 팀이 진행한 스타벅스 프로덕트 페이지 모델링을 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 을 작성한 것이다. 다음은 리뷰를 받고 난 뒤 수정사항이다.
리뷰를 받고 먼저 우리가 만든 것 보다 훨씬 더 개선할 수 있겠다 라는 생각이 들었다. 먼저 naming convention 과 자료 타입에 관한 것이다.
테이블 간 fk 로 연결하는 것에 관한 리뷰인데 피가되고 살이되는 피드백이였다. 먼저 우리팀이 했던 치명적인 실수에 대해서 알아보자.
예를들어 스타벅스에서 오징어 블렌디드를 출시했다고 가정해보자. 그러면 allergic_info 테이블에 새로운 컬럼을 추가해야한다. 그런데 이미 추가했던 이전 row 에 새로 생긴 오징어 컬럼을 다 추가해줘야 하기 때문에 memory cost 가 많이 든다.
보통 한 음료당 알러지가 한 두개 이기 때문에, 예를들어 우유, 대두만 있으면 나머지 알러지 컬럼은 쓸데없이 전부 false 로 채워야 되는 불편함이 있다. 혹은 모든 컬럼이 전부 false 가 될 수도 있다. 이런 경우에는 그 row 자체가 필요 없다.
--> 그렇기 때문에 many_to_many 로, allergy 테이블과 drinks 테이블을 잇는 테이블 allergy_drink 를 만든다. 새로운 알러지를 가진 상품이 추가되더라도 allergy 테이블에 새로운 알러지 컬럼 자체가 아니라 알러지 name 컬럼 값으로 들어가기 때문에, 기존의 컬럼에 영향을 주지 않는다.
one-to-one, one-to-many, many-to-many 의 개념이 모두 헷갈리는 개념이였다.
하지만 쉽게 생각할 수 있는 팁 몇가지를 소개한다.
아주 좋은 리뷰시간이었다.