주문, 결제 엔티티의 분류
132
작성한 질문수 11
"실전 개념적 모델링 - 시작" 파트를 들으면서 궁금한 점이 있어 질문드립니다.
주문, 결제 엔티티의 경우, 주문은 '결제'까지 포함하는 비즈니스 트랜잭션 단위라 하였는데, 왜 두개의 엔티티로 분류해야하는지 궁금합니다.
현재 요구사항에서는 하나로 합쳐도 문제가 없는건가요?
답변 1
1
안녕하세요, 쿠카이든입니다.
주문과 결제를 하나의 트랜잭션 단위로 서비스를 구현할 때,
주문과 결제를 각각의 엔티티로 분류하여 데이터를 분리시키는 것이 더 올바른 설계라고 생각됩니다.
하나로 합친다면 정규화가 제대로 이루어지지 않아서 데이터의 정합성이 깨질 현상이 발생할 우려가 있기 때문입니다.
즉, 두개의 엔티티로 하나의 트랜잭션을 설계하는 것이 나은 선택이라고 생각합니다.
감사합니다
용어 사전
0
27
2
개념적 모델링 - 실습
0
26
1
DB 설계와 JPA 관련 질문입니다
0
26
1
아주 작은 정오표 전달드립니다.
0
61
2
실제로 작은 기업에서 기획 롤
1
31
1
order_product 까마귀발
0
49
2
[DB설계] 탈퇴 유저의 구독 정보 유지 및 이메일 마스킹 관련 질문입니다.
0
58
1
자연키 vs 대리키 실무질문
0
28
1
1:N 관계에서 중간테이블 (연관엔티티)
0
59
2
일대일 fk 위치
0
48
1
제 3 정규형 vs BCNF 정규형 차이점?
0
116
3
BCNF 질문
0
80
2
연관 엔티티 네이밍 규칙
0
54
1
진짜 강의 듣는거 너무 고문
0
150
1
28강 sql 파일 어딨나여?
0
94
1
2NF의 엄밀한 정의
0
76
1
comment 채번을 사용해야 하는 이유에 대한 설명이 필요합니다.
0
132
4
학습중인 수업자료를 받아볼 수 있을까요??
0
103
2
수업자료 pdf파일관련 건의 - 제목 링크위치 개선
0
93
2
서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문
1
110
2
실무적인 설계로 접근했을 때 제 2정규형 항상 만족?
0
82
1
슈퍼/서브 타입 joined 전략
0
74
2
created_at 관련 구현과 DB ENUM에 대해
0
75
1
M:N 관계의 연관 엔티티 설계 순서
0
83
2