모델링관련
1) 보통 DB와 models.py에 코딩한 테이블을 기준으로 데이터를 뿌려주는게 일반적이지만 모델링/카테고리화가 까다로운 웹페이지의 경우 html을 통째로 저장해 프론트에다가 바로 뿌려주는 방식도 존재한다.
2) '좋아요(Like)'기능은 User - Product 사이에 ManytoMany로 중간테이블을 생성해서 하고, 따로 이를 count할 필요는 없으며, delete on=cacade로 삭제해버리면 된다.
3) 지도 API에 필요한 데이터항목들
- 위도 및 경도
- 매장정보
- 지도데이터
4) 비회원 / 회원마다 달라지는 페이지가 있으므로(ex : 비회원일 경우 쿠키에 저장, 회원일 경우 DB에 저장 등)이를 잘 생각해서 모델링을 해야함. 비회원-회원 여부 표시테이블
5) 이미지 URL 확장성 개선을 위한 타입칼럼
만약 이미지 테이블이 ID / IMG / SUBIMG 로 처음으로 칼럼을 생성했던 경우
bestIMG, ThemeIMG라는 항목을 칼럼에 추가하는 경우 테이블형태를 유지해야하므로 그 전까지의 칼럼에 이어지는 테이블에는 null값을 집어넣고 테이블을 수정할 수 밖에 없다.
예를 들자면..
| ID | IMG | SUBIMG | bestIMG | ThemeIMG |
|---|---|---|---|---|
| 1 | 사진 | 사진 | null | null |
| 2 | 사진 | 사진 | null | null |
| 3 | 사진 | 사진 | 사진 | 사진 |
이런식으로 null값이 들어간 테이블을 무조건 만들어야 한다.
이 경우 이미지테이블 안에 type-id / product-id 라는 테이블을 생성한다면 다음과 같이 확장성을 높일 수 있다.
| ID | IMG | type-id | product-id |
|---|---|---|---|
| 1 | 사진 | 1 | 1 |
| 2 | 사진 | 2 | 1 |
| 3 | 사진 | 3 | 1 |
type id : 1 = IMG, 2 = subIMG, 3 = bestIMG, 4= themeIMG
type id와 product id는 각각 테이블을 생성해 join하고
타입명과 제품명은 그쪽 테이블에 기입해서 관리해두면 편리하다.
| ID | Type_name |
|---|---|
| 1 | IMG |
| 2 | subIMG |
| 3 | bestIMG |
| 4 | themeIMG |
6) 실무에서는 유저테이블과 유저프로필 테이블을 따로 나누진 않는다.
7) 색깔별로 이미지의 개수가 달라지고, 상품과 색깔이 ManytoManyField로 연결되어있는 경우 이미지는 Product에 연결하는 것 보다 상품-색깔 중간 테이블에 연결 해주는 것이 좋다.
