Open rimo030 opened 8 months ago
시간 값을 왜 저장하는지 이해하기 어려울 거 같아서 제 생각을 정리해봤어요.
이 두 케이스 중 정답을 알려면 구매 내역 테이블을 확인해서, 장바구니가 삭제된 시간에 맞춰서 구매 내역에 상품 아이디가 기록이 되었는지, 또는 구매 내역의 테이블에서 장바구니를 가리키는 아이디 값이 있는지를 체크하면 됩니다. DB 입장에서는 지운 거지만 실제 현실에서는 그게 장바구니를 비운 것인지 아니면 구매가 된 것인지 알 방법이 없기 때문에 다른 테이블과의 연관관계로 논리적으로 추론해야 합니다.
그냥 실수일 가능성이 높습니다. 하지만 생성 날짜와 수정 날짜가 다르다면, 예를 들어 물건의 구매 수량을 변경하는 등의 액션이 취해졌더라면, 그건 실수가 아닐 수도 있을 거 같아요.
유저에게 직접 물어보지 않는 이상 정답을 알 방법은 없어요, 하지만 대략적인 추론은 가능할 텐데, 다만 추론을 위해서도 밑작업이 필요할 거 같아요. 먼저 서버의 접속 기록을 저장해야겠죠? 로그만 있다면 유저가 장바구니에 물건이 담긴 사실을 인지하고 있는지 확인해볼 수 있어요. 만약 로그인 자체가 한 달만이라면 그 유저는 아예 잊고 있었을 확률이 높고, 로그인은 자주 했지만 장바구니를 보질 않았다면 오랜만에 장바구니 청소를 했을 뿐일지도 몰라요. 하지만 주기적으로 장바구니를 보고 있었다면 정말로 고민을 했을 확률이 높을 거에요.
추가적으로 동일 카테고리의 다른 물건을 넣고 빼기를 반복하고 있다면 장바구니에서 물건을 담고 빼는 데 걸린 시간이 5분이라고 하더라도 실질적으로는 그 이상 고민한 것으로 간주할 수 있을 거에요. 예를 들어 A, B, C 사의 노트북을 돌아가면서 넣고 빼기를 반복한다면 각각의 상품을 5분 고민했기보다는 노트북이라는 카테고리에서 15분을 고민하고 있다고 보는 게 맞지 않을까요?
만약 평균적으로 ( 또는 중앙값으로 ) 5분을 고민하는 유저가 있다고 해봅시다. 그러면 이 유저에게 할인 쿠폰을 발급하기에 가장 적절한 시간은, 적어도 5분 이후는 아닐 거에요. 이 유저가 이미 물건을 포기했을 가능성이 높으니깐 고민이 길어지면서도 평균적인 고민 시간보다는 좀 이르게 쿠폰을 발급해야 해요. 하지만 너무 빨리 쿠폰을 발급하면 어차피 살 물건을 더 저렴하게 파는 꼴이 되버리겠죠.
비회원으로 구매한 사람은 우리의 유저가 아닐까요?
비회원으로 구매한 사람의 일절 없다면, 동일 인물이 비회원으로 100개의 물건을 산 걸 가지고 우리는 100명의 유저가 있다고 착각할 거고, 또 유저 당 거래액도 심한 경우 백분의 일로 착각하고 말 거에요. 그래서 아직 가입하지 않은 사람들을 유저로 칭하고, 회원가입을 한 사람을 멤버로 칭하든 해야 할 거에요.
유저에게도 코드를 발급하고 회원가입 없이도 임의의 코드 값으로 그 사람을 식별할 수 있게 만들어요. 그리고 언젠가 그 사람이 가입하는 시점에 맞춰서 멤버 테이블에 저장해요. 그러면 유저와 멤버를 연결지으면, 이 사람이 가입하기 전에 어떻게 활동해왔는지도 알 수 있고, 혹여 다른 유저 여럿이 사실 하나의 멤버라는 것을 추론해낼 수 있을지도 몰라요. 데이터는 이렇게 비즈니스에 굉장히 중요한 자산이라서 쉽게 삭제해서도 안 되고 미싱 링크를 만들어서도 안 돼요.
아하 모먼트
라는 개념은 개발적인 내용은 아니지만 알아두면 좋겠어요. 유저가 우리 서비스에 가치를 느끼는 순간을 의미하는데, 페이스북에서는 7명의 사람을 친구로 등록한 사람은 페이스북을 쓰게 된다고 해요. 당연한 얘기지만 SNS에 아무 친구도 없다면 굳이 할 이유가 없잖아요?
커머스도 물건을 5번 이상 구매해본 사람들은 우리 커머스를 계속 쓰더라~ 라는 식의 법칙을 발견할 수 있을지 몰라요.
그렇다면 어떻게든 5번 구매를 하게 만들기 위해서 회원가입 이후 5개 물건을 구입하기 전까지는 쿠폰을 발급해줄 수도 있겠죠? 개발자라고 무조건 실무 기술만 익힐 게 아니라, CS에 대한 근본적인 물음을 던질 줄도 알고, 비즈니스적인 역량도 있어야 한다고 생각해요. 특히 데이터베이스는 이 세 가지가 집대성된 것이기 때문에 더 더욱요.
커머스 ERD를 작성했습니다 !
https://github.com/rimo030/Repo-Server/issues/14#issuecomment-1792880203
https://github.com/rimo030/Repo-Server/pull/19#discussion_r1382491588 type length 대한 자료는.. 배달의민족 ERD 를 참고하였습니다.
https://github.com/rimo030/Repo-Server/issues/14#issuecomment-1793331530
entity
수정 예정id
, createAt
, updateAt
, deleteAt
칼럼을 공통적으로 가지게 됩니다.
(ERD 상에는 id외에 표현 되지 않았습니다.)테이블명_id
칼럼을 가지게 됩니다.seller
: id외에 비밀번호, 이름, 이메일, 전화번호, 사업자 번호를 추가product_bundle
: 계산방법 칼럼명을 calculation
→ shipping_calculation
으로 변경product_input_option
: 입력의 필수 여부를 확인하는 required
칼럼을 추가cart
, cart _required_option
: 수량을 의미하는 count
칼럼 추가cart_input_option
: 사용자가 입력한 옵션의 값 value
칼럼 추가title
→ value
로 변경추가적으로 Common table을 만들고 createdAt, updatedAt, deletedAt은 모든 테이블에 넣을 거라고 명시해주는 게 ERD가 더 깔끔할 거 같긴 합니다.
https://github.com/rimo030/Repo-Server/issues/14#issuecomment-1793760650
네 추가적으로 테이블과 칼럼을 추가하였습니다!
이를 바탕으로 #19 Entitiy를 수정하겠습니다.
오타수정했습니다..
이렇게 적용 및 추가 학습해보시고 커머스 ERD를 그려보세요. 이건 ERDCloud로 커머스 예제를 검색해보시고, ERDCloud나 drawio로 그림을 그려서 github issue로 올려주세요. 변경사항이 생길 때마다 논의할 수 있게 원본 파일도 항상 저장해주시고, ERD 그리는 법은 형식에 연연하지 말아주세요. "아직은"
Originally posted by @kakasoo in https://github.com/rimo030/Repo-Server/issues/13#issuecomment-1791740480
createdAt/updatedAt/deletedAt Column
NOW()
를 사용해 현재 시간을 기입DATETIME / TIMESTAMP
기본적으로 NOT NULL
Timezone 기반
9999-12-31
9999-12-31 23:59:59
2038-01-1903:14:07 UTC
hard delete/soft-delete
데이터베이스에서 데이터를 삭제하는 방법에는 물리삭제(hard delete)와 논리삭제(soft delete)가 있다.
논리 삭제를 이용하는 이유는 삭제된 데이터를 추후에 사용할 가능성 (데이터복원 및 데이터 분석) 이 있기 때문이다.