지난주에 작성한 모델링을 장고로 옮겨보았다.
그 중 장고 모델 작성을 위해 일부 수정하고, 일대다, 다대다, 일대일 관계를 장고로 만드는 연습을 하는 중이다.
"product-nutrition" 의 관계를 생각했을 때, 저번에는 product 안에 nutrition 을 저장하고 FK로 nutrition id 를 가져왔었다.
이렇게 one-to-one 관계를 장고에서 모델링 하는 방법을 유투브에서 찾아봤는데, 주로 예시로 드는 건 사용자와 프로필이었다.
사용자 한 명당 프로필 하나. 음료 하나당 영양정보 하나. 그리고 모든 영양정보는 서로 다르다. 그래서 "user-profile" 를 어떻게 모델링 하나 살펴봤는데 user 안에 profile id 를 넣는게 아니라 그 반대로 했다.
user 안에는 profile 관련 attribute 는 없고, profile 안에 user 를 넣었다. 그래서 user 정보가 삭제되면(탈퇴 등) profile 도 삭제하게 on_delete=models.CASCADE 를 적용해주었다.
모델링을 수정 안하고 그대로 배꼈다면, 영양정보가 사라지면 음료가 하나 사라지는 기현상이 나타날 뻔 했다. 아래는 수정한 모델링과 models.
(Nutritions 의 size 는 일대다 관계긴 한데 삭제하면 어떻게 할지 아직 생각 못했다..!)
모든 음료는 어떤 카테고리에 속한다. 에스프레소, 블렌디드, 프라푸치노 등등.. 각 카테고리 안에 여러개의 음료가 있다. 카테고리 하나당, 음료 여러개; One to Many 관계이다.
모델과 코드를 보자.
음료가 카테고리에 종속되므로, 음료 안에 카테고리를 쓰고 카테고리가 사라지면 음료도 사라지게 해뒀다.
이건 장고 공홈 튜토리얼에서 연습했던 Question-Choice 와 비슷하다. 한 문제당 여러개의 답이 있고 이를 고를 수 있게 만들었는데, 문제가 사라지면 답도 다 사라지게 설정했었다. 그 코드를 가져다 썼다^^..
모델링 할때 어려웠던 부분인데, 알레르기와 음료를 테이블로 만들 때 many to many 여서 어려웠다. 그래서 aquerytool 에서 연결 테이블을 따로 만들어줬는데, 이를 코드로 구현하면 해당 테이블을 클래스로 만들어 줘야 하는지, 아니면 many to many 로 써서 연결 테이블을 내재화 시키는건지 헷갈린다.