1.
사용자는 Every-Cheap 서비스에 회원가입을 할 수 있다.
a.
회원가입을 할 때 username, phoneNumber, password를 입력 받는다.
i.
username 은 영소문자 4 - 10 글자 형식이다.
1.
username은 중복이 불가능 하다.
ii.
phoneNumber은 010 - 9999 - 9999 형식으로 이뤄져야 한다.
iii.
password 는 영소문자, 대문자, 특수문자, 숫자를 포함한 8 - 15 자리 형식
2.
사용자는 Naver /Google /kakao / 로컬 로그인 을 통해 서비스에 가입할 수 있다.
a.
소셜 로그인을 통해 가입한 사람은 구매 혹은 입찰 시도 시 본인 인증 절차를 한 번만 거친다.
i.
이미 인증된 사용자라면 본인 인증은 패스한다.
b.
로컬 로그인을 통해 가입한 사람은 구매 혹은 입찰 시도 시 본인 인증 절차를 한 번만 거친다.
i.
로컬 로그인시 username, password를 입력 받는다.
1.
로그인시 회원가입과 마찬가지로 형식의 검증을 한다.
c.
사용자는 프로필을 수정할 수 있다.
i.
password 를 수정할 수 있다.
3.
본인 인증된 사용자는 상품을 구매 할 수 있다.
a.
상품은 관리자만 등록할 수 있다. 관리자는 서비스 개발자로 제한한다.
b.
상품 구매 시 쿠폰을 적용할 수 있다.
i.
쿠폰은 퍼센트 할인 과 금액 할인 으로 나뉜다.
ii.
쿠폰은 발급 된다. → 선착순 이벤트와 같은 요소를 고려해서 대용량 트래픽 필요
iii.
경매에는 적용할 수 없다.
iv.
하나의 상품에는 하나의 쿠폰만 적용할 수 있다.
c.
상품은 단일로만 구매할 수 있다. (대신, 같은 상품을 여러 개 구매할 수 있다.)
d.
상품의 재고보다 많은 수는 구매 할 수 없다.
e.
재고가 하나인 상품을 동시에 구매할 경우, 결제를 먼저 완료한 사람에게 구매 기회가 주어진다.
4.
관리자는 경매를 등록하고, 오픈할 수 있다.
a.
경매는 상품의 이름을 경매 이름으로 표기한다.
b.
경매는 경매 이름 몇분으로 설정할지, 시작 가격, 상품 이미지, 경매 시작 시간으로 등록할 수 있다.
i.
현재 가격은 경매가 등록될 때 시작 가격으로 정의한다.
ii.
시작 시간 + 경매 시간이 현재 시간 대비 지났으면 경매는 종료된다.
1.
경매가 종료되면 최고 입찰자는 해당 상품에 대해서 결제 여부를 선택할 수 있다.
5.
사용자는 상품을 입찰 할 수 있다.
a.
입찰을 해당 현재 경매의 현재 가격보다 적은 금액으로 입찰 할 수 없다.
b.
입찰 받고 상품을 구매하지 않으면, black 횟수가 1회 누적되며, 3회 누적될 경우 블랙 리스트에 등록되고, 다시는 가입할 수 없다. (전화번호로 확인)
c.
가장 높은 가격으로 입찰 한 사람이 구매하지 않으면, 그 다음으로 높은 가격으로 입찰한 사람에게 구매 기회가 주어지며, 이 과정은 세번째 입찰자에게 까지만 넘어가고, 세번째 입찰자도 구매하지 않는다면 유찰된다.
6.
결제 시스템은 구축 보류 중 (api 유료 이슈)
쿠폰 발급
•
쿠폰 일련번호를 각각 다르게 100개를 준다 > 사용자에게 쿠폰 지급하는 개념 → 사실 여기서 사용자가 쿠폰 리스트를 가져야 하지 않나 싶습니다
•
쿠폰 일련번호를 똑같이 주되, 개수 컬럼을 추가해서 100개인 것을 확인하는 방식입니다! >> 복합키를 주는거랑 같은방식
쿠폰 일련번호를 각각 다르게 하면, db 부하가 너무 커질 수 있을 것 같아서 걱정됩니다!! 제가 지금 마이크를 못 켜는 상황이라 죄송해요.
•
넵! 넵 어떤 말씀이신지 잘 이해가 안 됐읍니다.
•
쿠폰 이름이 같아도 일련번호가 다를 수 있는거죠!
◦
그래서 일련번호가 다르면, entity는 사실상 달라지는 걸로 이해했습니다.
◦
그러면 사용자는 여러개의 쿠폰 entity를 가질 수 있으니, 일대다 관계로 이해했습니다.
◦
사실 다대다 나오는게 좋지 않다고 해요!
◦
답을 찾으려고 노력해봤고, 두 가지의 선택지가 나왔고 한 가지를 선택했는데 여러 상황이 우려가 된다면 튜터님께 한 번 여쭤보고 속시원한 답을 얻는 것도 좋을 것 같습니다.
음 일단 저희가 선착순으로 쿠폰 발급하는 로직을 생각하고 있었는데요,
만약에 만 장의 쿠폰을 발급한다고 생각했을 때, 이건 종류가 하나라서 괜찮지만
여러개의 종류의 쿠폰을 다량 생산해야 한다고 생각했을 때, db에 들어있는 값이 너무 커지지 않을까 하는 마음과
어떤 쿠폰이 써졌는지 확인하기 위해
db를 조회하는 측면에서 저렇게 데이터가 많아지면 어떡하지? 라는 걱정에서 db 부하를 걱정했던 것 같습니다.
20장을 쏘았는데 20장을 다 가져갔는지 어떻게 알아요? >> 맞아요! 그래서 제가! 제가!!! 아까 개수를 얘기한 것 !!!
그게 지금 어렵읍니다… 그래서 그런 부분을 여쭤보고 싶었는데 지금 … 마이크가… 예….
주녕님 타임
재고 재고 하니까 생각을 잘못했을 수도 있겠다.
저는 개수로 가져가는 팝니다? 개수가 아니고 그 필드로 가져가~
네에~ 중간 테이블은 없고 어떻게 하는 거냐면
유저랑 쿠폰이 일대다.
쿠폰은 쿠폰의 이름이 있고 일련번호가 있고 얼마나 할인되는지 나와있고
우리 그대로 가져가고 limit 개수를 정해둔다 100
user가 클릭했을 때 쿠폰 하나가 user에게 들어온다
user가 가져온 coupon.getlimit = 100 발급됐으니까 —
그…
그게 제가…
말하던…
건…
데요….
이게…
고민이 뭐냐면요
이렇게 되면
쿠폰 100장에 엔티티가 하나거든뇨
그래서 이게 결국…
다대다…
? 다대다?.?.?.? 여러개…여러개… 아 돌아버리겠어요~!~!~!~!~!
쿠폰 20장 >>
개수 필드를 가져서 다대다 매핑 → 발급 될 때마다 - 쳐줘야 해서
update 쿼리가 계속 나감
하나의 종류의 쿠폰을 여러장 발급해서 엔티티를 여러개 만들고 일대다 매핑
→ 발급 될 때마다 count를 치면 되는데 이제 쿠폰이름이 코닥 이라고 하면 코닥이 몇개가 있냐:? 를
조회하는 쿼리가 계속 나감
사용자가 쿠폰을 발급 받으려고 누를거임
그 때 그냥 발급해주는 거예요 발급 api
처음에 쿠폰 100 개를 발급하는게 아니에요. 100 - 1
1 - 100
이벤트 테이블을 따로 >> limit
쿠폰 여러개
1.
토일월화 >> 대면피드백받기전까지 프론트를 진행안한다.
