그냥 logout으로 처리할 경우, spring security에서 logout을 사용하고 있기 때문에, redirect가 안먹음. logoutimpl로 처리시 먹음.
- 개인정보 수정날짜도 필요할수도.
- 상품 카테고리 추가하면 좋을수도.
- 프라이머리키 두개 설정할 수 있어. 장바구니의 경우는 상품번호 + 회원번호를 프라이머리키로 잡아서 중복된 데이터를 못들어가게 할 수도 있다.
- 문의, 후기글에 답글은 어떻게 쓰지? 예전 EMP테이블에서 MGR을 썼던거를 기억하자.
게시글번호 아래 상위글번호라는 칼럼을 만들어서 blank인 경우는 상위글.
상위글이 있다면 답글로 파악할 수가 있다.
댓글들의 경우는 대댓글 대대댓글이 있으므로 뎁스로 알 수 있다. - 관리자 테이블은 권한정보 등 테이블을 잘 만들어야 한다. 하지만 문의글에 관리자가 외래키로 잡혀있으면 안돼. 문의글을 남길때 마다 관리자번호가 들어가거든.
그럼 답글은 누가해? 관리자가 다는게 아니라 관리자격인 회원아이디로 답글을 다는 것이다. - 주문, 주문상세로 나눠야 한번에 여러 상품을 구입할 수 있다. <계약서 격의 테이블임>
주문엔 통째로 넣어놓고, 주문상세는 상세한 내용들이 나와있다. 주문 결제금액은 토탈금액. - 회원 - 주문 - 주문상세 - 상품 : 으로 연결되어야 한다. 주문과 상품은 연결되면 안돼. 연결되면 회원은 하나씩 상품을 주문한다가 되어버림.
- 주문 상세에는 각 제품 하나만 정보를 담고, 상품에 대한 할인정보를 넣을 수 있다.
- 주문에는 모든 제품 가격에 대해서 할인 정보를 넣을 수 있다.
- 주문에는 배송지가 있으면 안돼. 릴레이션이 있으면 안됨. 회원이 배송지를 모두 지워버리면? 원장이 꼬이기 시작한다.
- dw : 데이터 분석을 위한 테이블을 구축하고 데이터 분석을 진행한다.
erd는 흐름이 없다. 화면엔 흐름이 있기 때문에 같이 하면서
기능정의 : 서비스와 매퍼에 대한 기능정의.
사용자의 카트정보 조회.(기능추가 요청) 조회를 하면 어떤게 조회돼야해. -> 쿼리문을 생각하고 조인을 생각. -> 이 칼럼은 없어도 돼, 이 테이블은 있어야해. 고민 가능.
사용자의 주문정보 조회. 월별 매출액을 가져오자. 등
pom.xml수정
DTO수정
Controller수정
에러체크
다른페이지에서 detail?id= 이라는 클라이언트 요청을 받으면
컨트롤러 /detail로 간다.
cust의 정보를 담아서 detail 페이지에 정보를 뿌리면서 detail?id=에 응답한다.
redirect사용법 : /를 붙이면 절대경로에서 검색. 붙이지 않으면 현재 경로에서 이어서 작성됨.
erd 피드백:
장바구니 pk를 장바구니시퀀스로 안하고 회원번호 + 상품번호 조합으로 해도 됨.
찜 또한 마찬가지로 중복시켜도 됨.
히스토리 또한 매우 중요. 실무가면 히스토리 db가 매우 많을것
안녕하세요