스타벅스 서비스 모델링

task2: 스타벅스 음료 페이지를 모델링
필수 구현 사항 : 음료, 카테고리, 영양 정보, 알러지, 음료 이미지, 음료 설명, 신상 여부
구현 제외 사항 : 프로모션, 음료 사이즈

Table beverage {
  id int [PK]
  name varchar
  image block
  description varchar
  allergy varchar
  isnew boolean
  category_id int[FK]
  nutrition_id int[FK]
}

Table category {
  id int [PK]
  name varchar
}

Table nutrition {
  id int [PK]
  fat int
  kcal int
  sodium int
  sugar int
  protein int
  caff int
}

Ref : category.id < beverage.category_id

Ref : nutrition.id - beverage.nutrition_id

테이블 명은 소문자. 중복, 줄임말 지양(info → information). 보통 복수형태로 ex)dinks.
테이블 명이 두 단어면 스네이크 케이스 문법으로 연결.
뉴트리션(영양정보)는 한번에 많은 정보를 담고 있음.(음료마다 고유값이긴 하지만 양이 많기 때문에 따로 빼서 정규화해야 확장성, 유지보수 용이), 용량에 따라 달라질 수도 있음.
영양정보는 int보다는 decimal or float으로 정확한 데이터가 중요함.

img - 데이터타입은 클라우드에서 가져오는 경우가 많음(데이터 url로 가지고옴)

id명 같은 경우에 단수 형태
id 값은 새롭게 네이밍 하기 보다 그대로 id로(id_drink(x))
boolean tinyint 비교해보기. (파이썬에서 boolean줘도 sql에서 자동으로 tinyint로 변환됨.)
주가 되는 테이블을 가운데 배치시키는 게 좋음.
beverage - beverage_name(불필요) → beverage - name
화살표 방향은 FK → PK (PK는 FK에 물려있다(역참조))(FK는 PK를 물고있다(정참조))
이름이 고유하더라도 id값으로 PK지정해주는 것이 좋음(이름은 오타날 가능성이 높아짐)
이름도 생각보다 고유하지 않을 수도 있음 (가능성)