기본적으로는 json 사용을 자제하고 디비 구조에서 데이터 모순이 발생할 가능성을 최소화하고 싶었습니다.
또한, 확장성을 고려해 option 같은 경우도 별도의 테이블로 분리하여 관리하였습니다.
현재 기획에서 선택가능한 옵션이 두가지라고 해서 menu에 option을 column으로 넣어버리면 옵션을 추가할 때마다 column을 추가해야하기 때문입니다.
따라서, 초기 기획에서는 주문 내역 또한 option 값을 option 테이블의 외래키로 참조하여 가지고 있었습니다.
그러나 현재 기획으로는 주문 내역의 option 값으로 유의미한 작업을 하지 않기 때문에, 굳이 참조하여 가지고 있음으로써 얻는 이점이 없었습니다. 데이터를 추가, 조회하기에 불편함만 주었습니다.
그래서 큰 구조는 그대로 가져가되 주문 내역에선 option을 string 타입인 summary로 저장하도록 했습니다.
이 방식이 더 유리한 이유는 단순히 저장, 조회가 쉽다는 것 뿐만 아니라, 해당 주문 내역이 생성될 때의 선택 옵션 상태를 기록하기가 쉽다는 것도 있습니다.
만약 옵션 테이블의 값을 참조하여 기록한다면, 옵션 값이 바뀌었을 때 주문 내역에서도 바뀐 값을 참조하게 됩니다. 주문 내역은 주문 당시의 상황을 기록하는 것이 중요하지, 현재 상태를 반영할 필요는 없다고 생각합니다.
용어 변경
