프로젝트 2일차

오늘은 위코드 오프라인 첫날 처럼 눈이 흩날렸다.

진짜 집에서 이불뒤집어 쓰고 전기장판 키고 있고 싶었지만 그럴수 없었다. 오늘은 반드시 Aquery 모델링을 마무리하고, models.py의 작성에 들어가야 하기 때문이다.

오전 - 모델링의 수정!

가장 처음 작성한 aquery 이다. 전날에는 잘했다고 생각한 aquery이지만 보면 볼 수록 수정할 부분이 생겨나고, 손볼 곳이 자주 생겨났다.

수정사항
1. Product부분에 Full_name, created_at, upatde_at, opening_at이 빠졌었다. -> 추가 완료
2. story table의 변경

• 두 개 다 각각 테이블로 되어 있는데 굳이 이렇게 할 필요가 있나 싶어서 변경했다. image는 1개의 story당 여러개가 필요하기 때문에 만들 필요가 있다. 하지만 description관련테이블은 제거 후 column으로 만들어 주었다.
  

3 . orders 부분에 있는 address를 따로 테이블을 만들어 주었다.

• 와디즈의 리워드를 선택하고 마지막으로 카드번호, 결제정보를 입력하는 창으로 가게 되면 회원가입시에 기입한 정보가 있는 서포터즈를 제외하고, 리워드 배송지라고 따로 기입하는 창이 존재하고 있다. 만약 한 번 이라도 배송을 받은 적이 있다면 리워드 배송지에 입력하는 창 대신에 기존의 주소가 나오게 되어있다.
• 이 부분에 대해서 따로 테이블을 만들어서 주소를 저장하는 편이 나은지, 단순히 저장된 주소를 불러오는데, 굳이 따로 테이블을 만들지에 관련해서는 열띤 토론이 있었다. 결론은 address관련된 table을 만들어야 한다고 의견이 모아졌다.

4. 기획전 관련해서 추가하기

• 클라우드 펀딩 회사인 와디즈의 주된 기능인 펀딩하기를 메인페이지로 정해서 클론코딩을 하고 있지만, 원 와디즈 홈페이지에 있는 기획전 기능은 가져와서 상품 밑에 추가하기로했다.
  
• promotion 이라는 테이블을 따로 만들어서 기획전과 관련된 테이블을 따로 생성했다. 기획전 관련된 이름, 시작한 날짜, 끝나는 날짜를 칼럼으로 테이블을 만들어 추가 했다.

오후 - 1. 데이터베이스 모델링 리뷰!

aquery관련해서 멘토님과 리뷰가 있었고, 백엔드 대표로 와디즈 클론코딩 데이터베이스 모델링을 발표하게 되었다. 홈페이지를 띄워 놓고 모델링을 보고 설명했으면 더욱 자세하고 꼼꼼하게 어떤 생각을 가지고 모델링을 했는지 이야기 해드릴 수 있었을 테지만, 단순히 데이터베이스를 보고 어떤 데이터를 담을 생각으로 만들었는지, 참조를 어떻게 했는지를 설명하는데 생각보다 힘이 들었다.

멘토님이 말씀하신 수정 사항

1. price, rate, amount와 같이 정수로 표현해야 할 경우는 DecimalField로 해주는 것이 좋다.
2. rewards vs product_option

• 와디즈에서 reawrd라는 개념은 promotion을 의미한다. 하지만 다른 커머스 사이트를 보게 되면 이런 프로모션은 optional로 존재하고 있다. 그래서 Table 이름과 관련해서 reward보단 product_option이 더 낫지 않겠냐고 의견을 제시해 주었지만, 와디즈에서는 따로 단품으로 구매하는 기능이 존재하지않고, makers가 제시한 promotion을 기준으로 판매하기 때문에 reward가 낫다고 하셨다.

3. query이름은 소문자로

• 우리가 만든 aquery의 테이블 명이 django에서 models.py를 구현할때 대문자로 적어서 헷갈렸던것 같다.

4. order : address = 1 : 1

• 오전에 수정한 부분에 관련해서 피드백이 들어왔다. order와 address 관계를 생각했을때 우리 모두는 One To Many를 생각했다. 한 명의 서포터가 여러개의 주소를 가질 수 있기 때문이다. 하지만 주문을 하는데 있어서 Order와 address의 관계는 One To One 이 된다. 한 명의 support가 여러개의 주소를 가지고 있아 하더라도 배송을 보내는 주소는 한 개 이기 때문이다. 즉 한개의 Order와 address의 관계를 가지게 되는 것이다.

5. Menu 테이블의 제거

• wecode를 시작할때 스타벅스 모델링을 했었다.
  
  음료와 관련된 부분만 단편적은 모델링이었으나, Menu테이블을 만들어서 음료, 푸드, 상품... 과 같은 데이터를 넣었다.
  
  이번에도 마찬가지로 펀딩하기, 투자하기를 Menu에 넣어서 ForeignKey를 통해 참조하려고 했다.

  but!
  저희가 크게 간과한 부분이 있다. 데이터베이스 모델링을 하는 것은 데이터를 만들기 위한 장소를 만들기 위해 만드는 것이다. 클론코딩이라서 어쩔수 없이 홈페이지를 보고 데이터모델링을 하던 터라 당연한 실수이지만 조심해야할 부분으로 페이지를 고려하고 데이터 베이스 모델링을 만들어야 한다. 대개 홈페이지를 만들때 데이터베이스 모델링을 보고 만들어 가기때문이다.

  그래서!!!
  이번 프로젝트에서 주력하으로 구현하고자 하는 '펀딩하기'와 '투자하기'는 얼핏보면 비슷해보일 수도 있지만 완전히 다른 것이기 때문에 굳이 Menu테이블을 사용해서 할필요가 없다고 하셨다.

6 . Image,description을 관련해서 수정??이 아닌 고려하면 좋겠다.!!

멘토님께 우선적으로 팀원들과 논의한 내용을 먼저 말씀을 드렸다. Image와 Description이 섞여있다. 그래서 처음에는 Image테이블과 Description 테이블을 따로 나누어 Idkey를 통해 데이터를 불러오는 순서를 우리가 정하려고 했었다. 하지만 텍스트 파일을 굳이 나누어 저장하는 것이 먼가 이상해서 그냥 Image만 저장하고, 텍스트 파일만 저장하는 방식으로 바꾸었다.

답변
-> 모든 경우의 수를 다 생각해서 이방법, 저방법 생각을 해본 것은 너무나도 좋은 현상이다. 물론 그렇게 해도 되지만 지금은 굳이 그렇게 하기 보다는 FE가 만든 목데이터를 저장하는 테이블을 만드는 것이 더욱 좋은 것 같다.

7. Maker, Supporter

처음의 auery를 보게 되면 supporters와 Makers가 있다. Supporters는 회원가입을 하게되면 펀딩을 하게될 권한을 가지게 되는데 이들을 Supporters가 되는 것이다. 그리고 Makers는 펀딩을 개시한 사람을 의미한다. 그래서 이들 각각의 테이블을 만들었다. 이런 이유도 있지만 와디즈 홈페이지를 보면 Makers의 간단한 정보를 적은 부분이 있다. 이 부분을 구현하기 위해 Makers Table을 만든 이유가 가장 크다.
-> 지금와서 보면 이 오류도 홈페이지를 보고 데이터모델링을 하다보니 생긴 오류였다.

천천히 다시 살펴보면 회원가입을 하는데 있어 서포터와 메이커가 따로 진행하는 것이 아니라, 두 개의 권한을 모두 다 가지게 된다. 메이커로서 펀딩을 시작하기 위해서는 추가적인 정보가 필요한 것이었다. 그래서 supporter와 maker로 나누기 보단 User의 정보를 가지고 있는 테이블을 따로 만들고, 추가로 받아야 하는 테이블을 참조를 거는 방식으로 수정했다.

추가 의논, 수정

이 부분에 관련해서 처음에는 Products테이블에 '달성률', '펀딩금액', '서포터즈수'로 해서 각각의 테이블을 넣어주었다. 하지만, 생각을 해보면 굳이 이들의 테이블을 넣어줄 필요가 없다는 생각이 들었다. 엄현히 말해서 서포터즈의 수가 증가함에 따라 이들은 자동적으로 새로 갱신이 되기때문이다. CRUD를 생각해 보니, update를 하는 것이라 생각해서 이러한 데이터들을 넣어주는 column이 필요하다고 했다. 근데 굳이 과거의 데이터를 가지고 있을필요가 있을까? id를 통해 orders를 count를 한 뒤 reward에 있는 금액을 곱하거나 나누기를 하면 바로 알 수 있는 데이터이기 때문이다. 결과적으로는 굳이 필요하지 않을 칼럼이라서 제외하긴 했지만, 현업에서는 다 저장할지, 아니면 계산으로 할지 궁금하긴 하다!