Review에서 ReviewKey에 대하여
안녕하세요 제미니님 강의를 보다 궁금한 점이 생겨 질문드립니다.
리뷰 작성 시 주문아이템 건에 대해 한 건의 리뷰만 작성 가능하도록 요구사항을 잡고 작성하셨습니다.
따라서 새로운 리뷰를 작성할 때 해당 상품에 대한 주문아이템 리스트를 조회하여 아직 기간 내에 작성하지 않은 주문아이템이 있을 시 작성이 가능하도록 하셨는데요.
이런 경우 ReviewKey없이 바로 주문아이템 건에 대한 FK를 잡아도 될거 같은데 FK를 잡지 않고 ReviewKey를 별도로 만드신 이유가 궁금합니다 !
Answer 2
0
지헌님 질문 감사드립니다!
생각보다 단순한 문제입니다! 리뷰는 지금 보편적으로 활용 할 수 있도록 의도적으로 테이블이 구현되어있습니다!
그리고 엔티티에 유니크 인덱스 정보를 보시면 userId, reviewKey 만 존재하고 있습니다!
이 경우로 상상해보시면 주문 외에 판매자, 브랜드 등등 리뷰 시스템이 확장 되었을때 단순히 targetId 로 Key 를 잡는다면 유니크 키 충돌이 발생할 것입니다!
ex) A User 에게 OrderItemId = 1 이 존재하는데, BrandVoteId = 1 이 존재하면 두 값이 충돌이 날 것입니다
BrandVoteId <= 브랜드 투표 시 리뷰를 남길 수 있는 것 이라고 가정한다면..
일단 느낌이 보이시게 억지 예제를 짜봤는데 저런식으로 충돌 발생 가능성이 높다고 봐주시면 될 것 같습니다!
그렇기 때문에
ReviewTarget => Product
ReviewKey => 실제 리뷰를 작성하는 대상에 대한 고유 값
이렇게 구성이 된 것이라고 이해해주시면 될 것 같습니다!
완강까지 쭉쭉 잘 부탁드립니다! 감사합니다!
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
47
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
44
2
SettlementTargetRepository Jquery 질문
1
48
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
60
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
67
2
제미니님 안녕하세요!
1
73
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
80
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
75
2
새로 개발한다면 구현 순서
1
133
1
의존 방향에 대한 고민
1
122
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
95
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
83
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
96
1
PG 결제 승인 로직
1
128
2
QnA에서 Join 필드 표현법
1
88
1
결제서비스 콜백 동시성문제 가능성
1
106
2
굿
1
107
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
135
2
도메인 객체와 엔티티 객체 사용
1
137
2
CouponService 의존성 의문
1
96
2
상품 목록 조회 고도화 질문
1
111
2
표현 계층에서의 접근 지점이 다양해지는것과 이를 해결하기 위한 파사드의 도입에 대해 제미니님의 생각이 궁금합니다.
1
123
2
제품상세 코드 느끼기
1
144
2
격벽의 순환 참조(?)
1
113
2