주문, 결제 엔티티의 분류
113
11 asked
"실전 개념적 모델링 - 시작" 파트를 들으면서 궁금한 점이 있어 질문드립니다.
주문, 결제 엔티티의 경우, 주문은 '결제'까지 포함하는 비즈니스 트랜잭션 단위라 하였는데, 왜 두개의 엔티티로 분류해야하는지 궁금합니다.
현재 요구사항에서는 하나로 합쳐도 문제가 없는건가요?
Answer 1
1
안녕하세요, 쿠카이든입니다.
주문과 결제를 하나의 트랜잭션 단위로 서비스를 구현할 때,
주문과 결제를 각각의 엔티티로 분류하여 데이터를 분리시키는 것이 더 올바른 설계라고 생각됩니다.
하나로 합친다면 정규화가 제대로 이루어지지 않아서 데이터의 정합성이 깨질 현상이 발생할 우려가 있기 때문입니다.
즉, 두개의 엔티티로 하나의 트랜잭션을 설계하는 것이 나은 선택이라고 생각합니다.
감사합니다
BCNF 질문
0
49
2
연관 엔티티 네이밍 규칙
0
40
1
진짜 강의 듣는거 너무 고문
0
114
1
28강 sql 파일 어딨나여?
0
79
1
2NF의 엄밀한 정의
0
66
1
comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
0
104
3
학습중인 수업자료를 받아볼 수 있을까요??
0
92
2
수업자료 pdf파일관련 건의 - 제목 링크위치 개선
0
79
2
서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문
1
96
2
실무적인 설계로 접근했을 때 제 2정규형 항상 만족?
0
71
1
슈퍼/서브 타입 joined 전략
0
64
2
created_at 관련 구현과 DB ENUM에 대해
0
64
1
M:N 관계의 연관 엔티티 설계 순서
0
67
2
데이터 역사성 훼손 문제
0
60
2
실무팁 - 등록자,수정자 컬럼 관리 관련 질문입니다.
0
78
1
구글이 이메일 변경을 허용하는 이유
0
117
1
order_item 테이블 (order_id, product_id) 유니크 제약조건 누락
0
97
2
BCNF 정규화에 대한 질문
0
117
2
실무에서의 복수 항목에 대한 관리 방법이 궁금합니다.
0
86
1
역할 및 발생 시점에 따른 엔티티 분류
0
82
1
대리키의 외부 노출에 대한 질문을 하고 싶습니다.
0
104
2
소프트 딜리트 정책에서 유니크 컬럼 중복 방지 전략
0
91
1
대리키 사용과 정규화
1
106
2
강의자료 까마귀발 잘못된거 아닌가요?
1
125
2