-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accommodation Schema #4
Comments
피드백
질문
|
시스템 컬럼 부분
AS-ISMOD_DTS DATETIME(6) NOT NULL COMMENT '등록일자',
MOD_USER_IDX INTEGER NOT NULL COMMENT '수정자',
REG_DTS DATETIME(6) NOT NULL COMMENT '등록일자',
REG_USER_IDX INTEGER NOT NULL COMMENT '등록자',
TO-BECREATED_AT ~ 등록일자
CREATED_BY ~ 등록자
LAST_MODIFIED_AT ~ 수정일자
LAST_MODIFIED_BY ~ 수정자 charset 누락
관계 설정
PK 부분도 숙박업체 권한 부분
객실과 객실 요금개인적인 생각으로는 객실에는 객실마다 기본 요금이 있을 것 같고, 추가 옵션 처럼 관리되는 요금이 있을 것 같습니다 :) |
Accommodation
RESPE_USER_IDX 부분은 나중에 PARTNER_CENTRAL_ID 로 바뀔 것 같습니다 :) 일단은 지금은 그대로 두셔도 될 것 같아요 ㅎㅎ
createdBy 와 lastModifiedBy 에 ACCOMMODATION_TYPE
ACCOMMODATION_TYPE 을 보면 FK 가 아무것도 안걸려있습니다. 숙박업체를 등록할때 타입을 먼저 선택하는데, ACCOMMODATION 쪽에 타입이 존재해야하지 않을까 생각합니다. 변경 가능성이 거의 없거나, 추가 되더라도 빈도가 엄청 낮은 경우에는 테이블로 관리하는 것도 괜찮고, 코드에서 Enum 으로 관리해도 충분하지 않을까 생각합니다.
어차피 등록할때 타입을 선택하고, 타입은 ACCOMMODATION 에 들어가야할 것 습니다😄 ACCOMMODATION_ROLE
진행 상태 코드 : 승인(APPROVAL) 과 반려(DENY), 대기(PENDING) ROLE 에
ACCOMMODATION_ROOM우선순위 관련 컬럼은 ACCOMMODATION_GROUP_COMMON_CODE
코드값이 UNIQUE 하더라도 PK 는 인조키로 잡는게 좋습니다. 어떤일이 발생할지 모르기때문에 ㅎㅎ 저는 PK 를 인조키로 생성하고, 코드값에 UNIQUE INDEX 를 걸어줄 것 같습니다 😄 ACCOMMODATION_ROOM_INFO
String codeValue; 그러면 다른 사람이 봤을때 codeValue 가 뭔지 짐작하지 못할 것 같습니다. 물론 @column 을 사용하여 필드명을 다른 것으로 바꿔줄 수 있겠지만, boolean 값을 받는 ACTIVE 컬럼으로 통일하면 좋지 않을까 생각합니다. boolean active
ACCOMMODATION_ROOM_FEE여기도 Y/N 컬럼에 대해서는 ACTIVE 라는 명칭을 사용하면 어떨까 생각합니다. 오타몇개 LAST_MODIFIED_AT DATETIME(6) NOT NULL COMMENT '등록일자', 이런식으로 컬럼과 COMMENT 가 매칭이 안되는 부분이 있습니다 :) CREATED_BY INTEGER NOT NULL COMMENT '등록자', 이런식으로 INTEGER 로 되어있는 오타도 있습니다.
|
[질문]
|
그러면 ID 로 통일하는 거로 하겠습니다 :)
id 값이 맞는데 만약에 id 값이 안들어가지거나(버그 등으로 인해) 혹은
ACCOMODATION_ROLE
이 두 컬럼은 뭔가 히스토리 테이블에 있어야 어울릴 것 같은데, 빼도 되지 않을까요? History table 을 안쓰니까, 추가하신거면 상관은 없을 것 같습니다 :) |
넵! 이건 수정했습니다~
아하 근데 만약 id 값이 들어갈 수가 없거나, 빈 값이라면 에러 발생이 맞지 않을까여? DEFAULT 지정하면 에러 없이 'SYSTEM'으로 데이터가 삽입될거 같아서 이 점은 운영으로 가져갈시에는 설정하지 않는게 낫지 않을까 라는 생각이 들어요! 시스템 관리자가 직접 수기/수정할 때에도 개인의 사번 등으로 직접 문자열을 넣지않을까요?!
숙박업체가 중지 상태로 변경됬을때 데이터를 넣어두려고 추가했습니다! 히스토리 테이블을 안써서 추가한거 맞아요!ㅎㅎ |
Aggregate 확정 과정 Aggregate첫번째[1] accommodation aggregate1.png Aggregate Root : ACCOMMODATION
두번째[2] accommodation aggregate2.png Aggregate Root : ACCOMMODATION [Aggregate : ACCOMMODATION_GROUP_COMMON_CODE] Aggregate Root : ACCOMMODATION_GROUP_COMMON_CODE
세번째 - 확정[3] accommodation aggregate3.png
[Aggregate : ACCOMMODATION_GROUP_COMMON_CODE]
[Aggregate : ACCOMMODATION_COMMON_CODE]
연관관계는 가지고있지만 같은 라이프사이클을 가졌다기에는 애매하고, 별도로 관리되는 테이블 데이터라고 생각해서 각각의 Aggregate로 분리 |
고생하셨습니다 ~ 👏👏👏 ATDD 하러 가시죠 ~ |
ACCOMMODATION (숙박업체)
ACCOMMODATION_TYPE (숙박업체 타입)
Enum
ACCOMMODATION_ROLE (숙박업체 권한)
ACCOMMODATION_ROOM (객실)
ACCOMMODATION_GROUP_COMMON_CODE (숙박업체 그룹 공통코드)
ACCOMMODATION_COMMON_CODE (숙박업체 공통코드)
비즈니스 시설 (A001)
상점
기타
ACCOMMODATION_ROOM_INFO (객실 부가정보)
ACCOMMODATION_ROOM_FEE (객실 요금)
테이블 관계
History
Aggregate
[3] accommodation aggregate3.png
[Aggregate : ACCOMMODATION]
2-1) ACCOMMODATION_ROOM_INFO
2-2) ACCOMMODATION_ROOM_FEE
[Aggregate : ACCOMMODATION_GROUP_COMMON_CODE]
[Aggregate : ACCOMMODATION_COMMON_CODE]
The text was updated successfully, but these errors were encountered: