[#3] DB 설계 Version_1.0 #26

memoer · 2022-06-15T08:15:27Z

Resolved DB 설계 #3

Description

COMMON

DELETE 매커니즘은 HardDelete가 아닌 SoftDelete로 진행했습니다.
- deletedAt 컬럼 사용
시간 관련 타입은 "DATETIME, DATE" 칼럼이 아닌 "TIMESTAMP"로 통일했습니다.
- 시간 관련 타입을 여러 개의 종류를 섞어서 쓸 경우, 시간 관련 데이터를 조작할 때 혼란이 올 가능성이 있기 때문입니다.
- "DATETIME, DATE" 같은 경우는 DB 커넥션 타임존에 관계없이 클라이언트로부터 입력된 값을 그대로 저장하고, TIMESTAMP같은 경우는 타임존에 따라 시간이 보정됩니다. 이로 인해 두 가지의 데이터 타입을 섞어 쓸 경우, 어느 API는 시간을 보정하는 로직이 생기고, 어느 API는 시간을 보정하는 로직이 생기지 않는 상황을 방지하기 위해 날짜 데이터 타입을 하나로 통일했고, TIMESTAMP로 통일했습니다.
외래키 같은 경우엔 제약을 걸지 않았습니다.
- 외래키 제약을 걸 경우, 데이터 일관성과 그에 따른 제약 때문에 성능 이슈가 발생할 수 있기 때문에 외래키를 물리적으로 제약 걸지 않았습니다.
- 외래키를 물리적으로 제약을 걸지 않았고, 해당 외래키에 대해서는 하나하나씩 인덱스를 생성했습니다. 왜냐하면, 외래키같은 경우 JOIN문으로 사용할 경우가 아주 많이 발생하는데, JOIN 문에서 성능 최적화를 위해서는 INNER TABLE의 조인키에 인덱스가 있어야 하기 때문입니다.
다대다 테이블의 이름 같은 경우, 해당 테이블이 다대다 테이블임을 명시하기 위해 중간에 "__"를 넣었고 양 옆에 연결되는 테이블을 적었습니다.
- Ex) room_category_dateil__room_type, room__room_facility
다대다 테이블에서 유니크 제약을 걸었습니다.
- room_category_detail__room_type 테이블에선, room_category_detail_id와 room_type_id를 한 쌍으로 유니크 제약을 걸었습니다.
- room__room_facilitiy 테이블에선, room_id와 facility_id 를 한 쌍으로 유니크 제약을 걸었습니다.
- 유니크 제약을 건 이유 -> MySQL의 InnoDB 에서는 PK가 물리적으로 디스크상에서 저장시 정렬하면서 저장됩니다. 다대다 테이블에서 PK를 2개의 로우에 대해서 걸어버릴 경우, 데이터 저장시 소팅되면서 저장되는 성능 이슈가 발생할 수 있습니다. 때문에 PK를 2개의 로우에 대해서 설정하지 않았고, 자동 증가 값인 AUTO_INCREMENT를 통해 설정했습니다. 이렇게 설정할 경우, 기본에 row 2개에 대해서 PK를 걸어버리는 상황과 달리 중복 이슈가 발생할 수 있습니다. "room__room_facility를 예로 들면, 방 하나에 대해서 동일한 편의시설이 저장되는 등.." 이러한 중복 이슈를 방지하기 위해 유니크 제약을 걸었습니다.

[TABLE] host

유저 별로 여러 개의 호스트를 가질 수 있기 때문에, host Table을 따로 뺐습니다. [1:다 관계]

[TABLE] user

is_active -> 활성화 여부를 판단
gender -> 성별
- 해당 컬럼은 향후로도 남자/여자 외에는 데이터 추가할 일이 전혀 없을 것 같으므로, 테이블을 따로 빼서 참조하는 식으로 설계하지 않았고 VARCHAR 타입으로 설계 이후, 애플리케이션 단에서 데이터 규격을 잡아 저장합니다.

[TABLE] room

(min/max)_number_of_nights -> 최소 숙박 일수, 최대 숙박 일수
- 사용자는 명시한 최소 숙박 일수 이상으로만 예약할 수 있습니다.
- 사용자는 명시한 최대 숙박 일수 이하로만 예약할 수 있습니다.
room_cnt -> 해당 방에 대한 개수
- 명시적으로 설정하지 않을 경우, DEFAULT 값은 1입니다.
- 방의 카테고리에는 "호텔"이 존재합니다. 어떠한 특정 카테고리에서는 방을 1개만 제공하는 서비스가 아닌 2개 이상을 제공할 수 있습니다. 때문에, 방의 개수를 지정할 컬럼을 추가했습니다.
- "호텔"같은 여러 방을 제공하는 카테고리가 아닌, 단순히 저택같은 경우 해당 컬럼의 값은 1입니다.
check_in, check_out
- 해당 방의 체크인/체크아웃 시간입니다.
- 해당 컬럼같은 경우, 날짜[2022/06/15 같은]의 존재가 필요없고, 또한 저희 기능상으론 체크인/체크아웃에 분단위[30분 같은]가 들어가지 않습니다.
- 최종적으로, 체크인/체크아웃은 "시간"단위로만 입력되기 때문에, 날짜타입[TIMESTAMP]가 아닌 VARCHAR 타입으로 설정했으며 이 경우, 저장시에는 "11"->11시(or)"15"->15시 형태로 저장됩니다.

[TABLE] room_price

특정 방에 대해서 월별로 가격을 설정하는 기능을 구현하기 위해 1:다 테이블로 설계했습니다.
price 는 해당 월[ex)month=1이면 1월]에 대한 기본 가격이며, weekly_price 는 주간 할인 가격입니다.

[TABLE] room_status

특정 방에 대한 상태값을 저장하는 테이블입니다.

현재 초기 기능 요구서에서 나온 상태값은 총 3개입니다.
- IN_OPERATION : 영업 중, 게스트가 숙소를 검색하고 예약 요청을 보내거나 예약 가능 날짜를 예약할 수 있습니다
- SHUT_DOWN : 운영 중지, 게스트가 숙소를 예약하거나 검색 결과에서 찾을 수 없습니다.
- DISABLED : 비활성화, 에어비앤비에서 영구적으로 숙소 비활성화
방에 대한 상태값을 초기 기능 요구서에서 정의한 상태값에서, 추후에 추가될 가능성이 높기 때문에 테이블을 따로 빼서 참조하게끔 했습니다.

[TABLE] room_photo

방에 대한 사진

order -> 방에서 노출시키는 사진에 대한 우선순위

[TABLE] room__room_faciltiy / room_facility / room_faciltiy_category

room_facility_category
- 해당 테이블을 통해 편의시설에 대한 카테고리를 설정합니다.
room_faciltiry
- 편의시설에 대한 이름과 설명을 저장하는 테이블입니다.
room__room_facility
- 방은 여러 개의 편의시설을 가질 수 있고, 편의시설 또한 여러 개의 방을 가질 수 있습니다. 때문에, 다대다 테이블로 설정했습니다.
- 방-편의시설을 "일:다"로 설계할 경우, 편의시설에 "드라이기"라는 아이템이 있을 경우 room_facility 테이블에서 "드라이기__roomId-1, 드라이기__roomId-2, 드라이기__romId-3" 으로 저장됩니다. 이 경우, 만약 "드라이기"라는 아이템의 이름을 변경해야 할 때는 "드라이기"의 모든 row에 대해서 이름을 변경해야 하기 때문에 변경지점이 한 곳이 아닌, 여러 개가 되어버립니다. 이를 방지하기 위해 다대다 테이블로 설계했습니다.

[TABLE] room_category / room_category_detail / room_type / room_category_detail__room_type

room_category -> "회원님의 숙소에 가장 적합한 유형을 선택하세요"에서 나오는 값들을 저장하는 테이블
room_category_detail -> 첫 번째 숙소 유형에 나오는 값들을 저장하는 테이블
- room_category 와 일:다 테이블여야 하는 이유 -> 가장 적합한 유형[room_category의 값]에 따라 나오는 값들이 다르기 때문
room_type -> 두 번째 숙소 유형에 나오는 값들을 저장하는 테이블
- "전체/개인실/다인실" 3개의 데이터만 존재한다.
room_category_detail__room_type -> 첫 번째 숙소 유형과 두 번째 숙소 유형을 연결짓는 테이블
- 첫 번째 숙소 유형과 달리 "다:다"테이블이 있는 이유 -> 두 번째 숙소 유형은 첫 번째 숙소 유형과는 달리, 테이블이 여러 개 존재하지도 않고, 상위 테이블에 따라 데이터가 달라지지 않는다. 두 번째 숙소 유형의 값 같은 경우 "전체/개인실/다인실" 3개 고정으로만 존재하며, 이를 사용하기 때문
- 첫 번째 숙소 유형에 나오는 값들과는 달리, "전체/개인실/다인실"로 고정이 되어 있고, 첫 번째 숙소 유형에 따라 "전체/개인실"만 있을 수도 있고 "전체/개인실/다인실" 전체가 있을 수도 있고, "다인실"만 있을 수 있다. 때문에, "전체/개인실/다인실" 3개의 row를 room_type 에서 생성하고, 이를 room_category_detail 이 가져다 사용하는 방식으로 진행합니다.

변경 사항

main/java/resources에 schema.sql 파일 추가

질문 사항

DB 컬럼 타입에서, ENUM 타입은 여러가지 이슈 때문에 사용하지 말아야 한다고 들었습니다. ENUM 타입일 경우, 완전하게 사용을 하지 않는 건지, 아니면 상황에 따라 유기적으로 사용을 할 수도 있는 지가 궁금합니다. 또한, 현업에서는 해당 타입을 어떻게 사용하는 지가 궁금합니다!
- ENUM 사용 이슈 -> 정규화 위반, ENUM의 데이터 수정 어려움, ENUM 값들에 대한 조회 어려움

기타

(Optaionl) 어떻게 테스트하셨나요?

hoon25 · 2022-06-15T14:23:45Z

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

다대다 테이블에서 위 설명과 같이 유니크를 걸면 값이 못들어 가지 않을까 싶습니다.
ex) room_room_facility 기준
기능예시

room_id가 1인 방에 대해서 호스트가 facility를 2개 (room_facility_id가 1,2)인 데이터를 추가
room_id가 2인 방에 대해서 호스트가 facility를 1개 (room_facility_id가 3)인 데이터를 추가
- insert into room_room_facility (room_id, room_facility_id) values(1 ,1)
- insert into room_room_facility (room_id, room_facility_id) values(1 ,2)
- insert into room_room_facility (room_id, room_facility_id) values(2 ,3)
위와 같이 동작할것 같은데 room_id, room_facility_id 가 유니크할 수 없다고 생각이 듭니다.

room_category 관련 테이블들 변경 제안입니다.

현재 ERD 기준으로 room테이블은 room_category_id, room_category_detail_id, room_type_id라는 컬럼을 FK로 가지고 있습니다.
room_category_detail_room_detail 테이블의 id로 room_category 관련 정보를 다 가져올 수 있다고 생각합니다.
- 의도적으로 반정규화를 추구한게 아니라면 아래와 같이 변경하는게 어떨지 제안드립니다.
추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.
- (숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

[변경전]

[변경제안]

room_price 테이블 컬럼 이름 변경 제안입니다.

weekly_price컬럼이 주간할인가격을 의미하므로 컬럼명을 weekly_discount_price로 명시적으로 적어주는게 좋지않을까 제안드립니다.

[변경전]
weekly_price
[변경후]
weekly_discount_price

room_facility 관련 테이블들 이름 변경 제안입니다.

room_category관련 테이블들과 구조가 비슷해 보여서 동일하게 네이밍을 통일시키는게 어떨까 제안드립니다.
- room_room_facility -> room_room_facility_detail
- room_facility. -> room_facility_detail
- room_facility_category. -> room_facility
근데.. 사실 facility기능만 보면 현재 네이밍 정책이 더 적절해보이긴 하는데 통일성도 중요하지 않은가 싶어서 얘기해봅니다..! 🤣

memoer · 2022-06-15T14:56:06Z

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

다대다 테이블에서 위 설명과 같이 유니크를 걸면 값이 못들어 가지 않을까 싶습니다. ex) room_room_facility 기준 기능예시

room_id가 1인 방에 대해서 호스트가 facility를 2개 (room_facility_id가 1,2)인 데이터를 추가

room_id가 2인 방에 대해서 호스트가 facility를 1개 (room_facility_id가 3)인 데이터를 추가

insert into room_room_facility (room_id, room_facility_id) values(1 ,1)

insert into room_room_facility (room_id, room_facility_id) values(1 ,2)

insert into room_room_facility (room_id, room_facility_id) values(2 ,3)

위와 같이 동작할것 같은데 room_id, room_facility_id 가 유니크할 수 없다고 생각이 듭니다.

값이 못 들어가게 하기 위해 유니크 제약을 걸었습니다.
만약에 유니크 제약을 걸지 않는다면 말씀하신 데이터를 추가한 이후에, 중복으로 insert into room_room_facility (room_id, room_facility_id) values(1 ,1) 를 추가하게 된다면 room_id가 1인 방이 facility_id가 1인 동일한 편의시설을 2개 갖게 됩니다. 이를 막기 위해서 유니크 제약을 걸었습니다.

유니크 제약은 각각이 아니라 복합으로 걸었습니다.
즉, (room_id, room_facility_id) 를 한 쌍으로 유니크 제약을 걸었습니다.
때문에 위에서 적은 예시인 3개의 insert 문은 모두 정상적으로 저장할 수 있습니다.

room_category 관련 테이블들 변경 제안입니다.

[변경전]
[변경제안]

현재 ERD 기준으로 room테이블은 room_category_id, room_category_detail_id, room_type_id라는 컬럼을 FK로 가지고 있습니다.

room_category_detail_room_detail 테이블의 id로 room_category 관련 정보를 다 가져올 수 있다고 생각합니다.

의도적으로 반정규화를 추구한게 아니라면 아래와 같이 변경하는게 어떨지 제안드립니다.

반정규화를 고려하진 않았습니다.
해당 DB 설계를 했을 당시, 관계를 중점적으로 생각하여 설계하였습니다.
제안주신 DB 설계같은 경우, 방과 카테고리의 관계가 없다고 생각합니다. "room_detail을 통해서 room_category에 접근할 수 있다"는 맞는 말씀이시지만, 이렇게 설계할 경우 관계가 무너진다고 생각합니다.
제안주신 DB인 경우에는 room_detail과 room_category_detail__room_type의 관계는 어떤 관계일까요?

추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.

(숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

room_count 컬럼은 카테고리에 있으면 안되는 컬럼입니다. room 테이블에 있어야 하는 컬럼입니다.
이유로는, "room_category, room_category_detail_ room_type" 테이블들은 서비스를 운영하는 "어드민" 즉, 서비스 관계자가 데이터를 만들어야 하는 테이블입니다.
이에 반해, room_count는 서비스를 사용하는 "사용자"가 입력해야 하는 값입니다.
room_count가 "room_category, room_category_detail_ room_type" 테이블에 존재하게 된다면, 어드민이 데이터를 넣을 때 "해당 카테고리의 방을 만들 때는 x개의 방만 서비스하도록 해라"로 호스팅을 하는 사용자에게 강제하는 느낌이 강합니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

weekly_price컬럼이 주간할인가격을 의미하므로 컬럼명을 weekly_discount_price로 명시적으로 적어주는게 좋지않을까 제안드립니다.

[변경전] weekly_price [변경후] weekly_discount_price

좋은 것 같습니다. 변경하는 이름이 명시적으로 어떤 뜻인지 와닿는 것 같습니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

room_category관련 테이블들과 구조가 비슷해 보여서 동일하게 네이밍을 통일시키는게 어떨까 제안드립니다.

room_room_facility -> room_room_facility_detail

room_facility. -> room_facility_detail

room_facility_category. -> room_facility

근데.. 사실 facility기능만 보면 현재 네이밍 정책이 더 적절해보이긴 하는데 통일성도 중요하지 않은가 싶어서 얘기해봅니다..! 🤣

음.. 저는 일단 네이밍을 더 중요시하게 생각합니다.
왜냐하면, 네이밍이 잘 되어 있지 않다면 로직을 짤 때도 혼란이 올 상황이 생길 수 있고, 저희와 같은 경우엔 절대 발생하지 않는 일이겠지만 저희와 같이 프로젝트를 진행할 새로운 분이 들어오시게 된다면, 이분에게도 History를 알려줘야 하는 상황이 생깁니다.
반면에, 네이밍이 잘 되어 있다면 로직을 짤 때 혼란이 올 상황의 가능성이 줄어드고, 새로운 참여자가 들어오게 된다고 하더라도 어떠한 것 의미하는 지 바로 파악이 가능하여 History를 알려주지 않아도 되는 상황이 생기기 때문입니다.
저는 현재 네이밍 정책으로 진행하고 싶습니다!

hoon25 · 2022-06-16T01:16:21Z

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

#26 (comment)
복합으로 걸으셨군요 이해했습니다!

room_category 관련 테이블들 변경 제안입니다.

[변경전]
[변경제안]

현재 ERD 기준으로 room테이블은 room_category_id, room_category_detail_id, room_type_id라는 컬럼을 FK로 가지고 있습니다.

room_category_detail_room_detail 테이블의 id로 room_category 관련 정보를 다 가져올 수 있다고 생각합니다.

의도적으로 반정규화를 추구한게 아니라면 아래와 같이 변경하는게 어떨지 제안드립니다.

반정규화를 고려하진 않았습니다. 해당 DB 설계를 했을 당시, 관계를 중점적으로 생각하여 설계하였습니다. 제안주신 DB 설계같은 경우, 방과 카테고리의 관계가 없다고 생각합니다. "room_detail을 통해서 room_category에 접근할 수 있다"는 맞는 말씀이시지만, 이렇게 설계할 경우 관계가 무너진다고 생각합니다. 제안주신 DB인 경우에는 room_detail과 room_category_detail__room_type의 관계는 어떤 관계일까요?

room_category_id - 1차 카테고리(회원님의 숙소 카테고리에 가장적합한 것을 고르세요)
room_category_detail_id - 2차 카테고리(숙소유형(아파트 호텔 / 타운하우스))
room_type_id - 숙소 유형(개인실/다인실)
room_category_detail_room_type 테이블의 id가 FK로 위의 3개정보를 가지고 있기때문에
room에서 카테고리 데이터를 가져올 수 있지 않을까요?

추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.

(숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

room_count 컬럼은 카테고리에 있으면 안되는 컬럼입니다. room 테이블에 있어야 하는 컬럼입니다. 이유로는, "room_category, room_category_detail_ room_type" 테이블들은 서비스를 운영하는 "어드민" 즉, 서비스 관계자가 데이터를 만들어야 하는 테이블입니다. 이에 반해, room_count는 서비스를 사용하는 "사용자"가 입력해야 하는 값입니다. room_count가 "room_category, room_category_detail_ room_type" 테이블에 존재하게 된다면, 어드민이 데이터를 넣을 때 "해당 카테고리의 방을 만들 때는 x개의 방만 서비스하도록 해라"로 호스팅을 하는 사용자에게 강제하는 느낌이 강합니다.

위에 기능을 봤을때 2-5개/5-10개/10개-100개 정해진 항목들 중에 사용자가 선택하게 하는 것으로 이해했는데 잘못된 해석일까요?

room_price 테이블 컬럼 이름 변경 제안입니다.

#26 (comment)
확인했습니다

room_facility 관련 테이블들 이름 변경 제안입니다.

#26 (comment)
그러면 facility쪽 네이밍은 그대로 진행하는거로 알고있겠습니다.

memoer · 2022-06-16T02:37:22Z

room_category 관련 테이블들 변경 제안입니다.

[변경전]
[변경제안]

현재 ERD 기준으로 room테이블은 room_category_id, room_category_detail_id, room_type_id라는 컬럼을 FK로 가지고 있습니다.

room_category_detail_room_detail 테이블의 id로 room_category 관련 정보를 다 가져올 수 있다고 생각합니다.

의도적으로 반정규화를 추구한게 아니라면 아래와 같이 변경하는게 어떨지 제안드립니다.

반정규화를 고려하진 않았습니다. 해당 DB 설계를 했을 당시, 관계를 중점적으로 생각하여 설계하였습니다. 제안주신 DB 설계같은 경우, 방과 카테고리의 관계가 없다고 생각합니다. "room_detail을 통해서 room_category에 접근할 수 있다"는 맞는 말씀이시지만, 이렇게 설계할 경우 관계가 무너진다고 생각합니다. 제안주신 DB인 경우에는 room_detail과 room_category_detail__room_type의 관계는 어떤 관계일까요?

room_category_id - 1차 카테고리(회원님의 숙소 카테고리에 가장적합한 것을 고르세요) room_category_detail_id - 2차 카테고리(숙소유형(아파트 호텔 / 타운하우스)) room_type_id - 숙소 유형(개인실/다인실) room_category_detail_room_type 테이블의 id가 FK로 위의 3개정보를 가지고 있기때문에 room에서 카테고리 데이터를 가져올 수 있지 않을까요?

넵 room에서 카테고리 데이터를 가져올 수 있습니다.
처음에 창훈님이 제안주실 때에 "room에서 room_category로 연결되어 데이터를 가져올 수 있다."라는 이유로 ERD 설계 변경이 납득이 되지 않았습니다.
하지만 생각해보니, 창훈님께서 제안주신 테이블 설계도가 데이터 정합성 측면에서 나은 것 같아보입니다.
창훈님께서 제안주신 테이블 설계도로 변경할 때에 각각의 테이블 이름 명을 바꾸는 게 나을 것 같아보이는데 어떻게 생각하시나요?

room_category -> room_root_category(or)room_parent_category
room_category_detail -> room_leaf_category(or)room_child_category
room_type -> room_type
room_category_detail__room_type -> room_category(or)room_category_rule

추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.

(숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

room_count 컬럼은 카테고리에 있으면 안되는 컬럼입니다. room 테이블에 있어야 하는 컬럼입니다. 이유로는, "room_category, room_category_detail_ room_type" 테이블들은 서비스를 운영하는 "어드민" 즉, 서비스 관계자가 데이터를 만들어야 하는 테이블입니다. 이에 반해, room_count는 서비스를 사용하는 "사용자"가 입력해야 하는 값입니다. room_count가 "room_category, room_category_detail_ room_type" 테이블에 존재하게 된다면, 어드민이 데이터를 넣을 때 "해당 카테고리의 방을 만들 때는 x개의 방만 서비스하도록 해라"로 호스팅을 하는 사용자에게 강제하는 느낌이 강합니다.

위에 기능을 봤을때 2-5개/5-10개/10개-100개 정해진 항목들 중에 사용자가 선택하게 하는 것으로 이해했는데 잘못된 해석일까요?

네, 맞습니다. 사용자가 선택하는 데이터가 맞습니다.
제가 말씀드리고 싶은 것은 아래와 같습니다.

a. room_category 테이블은 서비스 관계자인 어드민이 자기의 서비스엔 3개의 종류인 "저택, 아파트, 부티크 호텔"이 있을 거라고 가정하고 3개의 데이터를 저장합니다. 이 "저택, 아파트, 부티크 호텔"에 대한 카테고리는 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다.
b. room_category_detail 테이블은 서비스 관계자인 어드민이 "저택, 아파트, 호텔"에 대한 상세적인 카테고리를 저장합니다. 또한, 상세적인 카테고리를 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다.
c. room_type 테이블은 서비스 관계자인 어드민이 "전체, 개인실, 다인실" 3개를 저장합니다. 또한, 해당 데이터도 에어비앤비를 가입하는 상요자가 저장하는 데이터가 아닙니다.
데이터를 저장하는 관점에서 봤을 때, room_category, room_category_detail, room_type 테이블은 사용자가 데이터를 저장하는 테이블이 아니고, 서비스 관계자인 어드민이 저장하는 느낌이 강합니다. 이로 인해, 세 테이블에 대해 데이터를 저장할 때는 어드민 사이트에서 서비스 관계자인 어드민이 저장하게 됩니다.
여기서 room_count를 room_category_detail 로 넣게 된다면, 어드민 사이트에서 어드민이 room_category_detail 데이터를 추가할 때에 input 태그로 데이터를 넣을 수 있게 된다는 얘기가 되는데, 이 경우 "특정 카테고리 상세 유형에서는 x개의 방을 서비스 제공하라"라고 강제하는 느낌이 강하다는 말이였습니다.
예를 들어, "부티크 호텔[room_category]-호텔[room_category_detail]" 과 "부티크 호텔-리조트" 2개의 room_category_detail이 있을 경우, room_category_detail 이 room_count에 있게 된다면 서비스 관계자인 어드민이 "호텔, 리조트"의 데이터를 등록할 때 room_count도 같이 등록하게 되어 해당 "room_category_detail "호텔, 리조트"를 제공할 때는 내가 이미 정해놓은 room_count에 맞게 제공해라." 라는 느낌이 됩니다.
"부티크 호텔-호텔"과 "부티크 호텔-리조트"에 대해서 room_category_detail 테이블의 데이터는 2개가 존재하게 됩니다.
room은 해당 room_category_detail에 연결되는 구조를 갖게 됩니다.
방이 5개가 있다고 가정하고, 방의 2개가 호텔이고, 리조트가 3개라고 연결됐다고 가정해봅니다.
여기서 room_count는 room_category_detail에 있는 컬럼이니 "호텔, 리조트"에 종속됩니다. 또한, 방을 만드는 사용자 입장에서는 room_count를 선택하여 설정할 수 없으니, 어드민 관계자가 이미 만들어 놓은 "호텔에서는 x개의 방을 제공하라"에 따라야 합니다. 사용자가 방의 개수를 선택할 수 없게 됩니다.

hoon25 · 2022-06-16T04:27:56Z

room_category 관련 테이블들 변경 제안입니다.

[변경전]
[변경제안]

현재 ERD 기준으로 room테이블은 room_category_id, room_category_detail_id, room_type_id라는 컬럼을 FK로 가지고 있습니다.

room_category_detail_room_detail 테이블의 id로 room_category 관련 정보를 다 가져올 수 있다고 생각합니다.

의도적으로 반정규화를 추구한게 아니라면 아래와 같이 변경하는게 어떨지 제안드립니다.

반정규화를 고려하진 않았습니다. 해당 DB 설계를 했을 당시, 관계를 중점적으로 생각하여 설계하였습니다. 제안주신 DB 설계같은 경우, 방과 카테고리의 관계가 없다고 생각합니다. "room_detail을 통해서 room_category에 접근할 수 있다"는 맞는 말씀이시지만, 이렇게 설계할 경우 관계가 무너진다고 생각합니다. 제안주신 DB인 경우에는 room_detail과 room_category_detail__room_type의 관계는 어떤 관계일까요?

room_category_id - 1차 카테고리(회원님의 숙소 카테고리에 가장적합한 것을 고르세요) room_category_detail_id - 2차 카테고리(숙소유형(아파트 호텔 / 타운하우스)) room_type_id - 숙소 유형(개인실/다인실) room_category_detail_room_type 테이블의 id가 FK로 위의 3개정보를 가지고 있기때문에 room에서 카테고리 데이터를 가져올 수 있지 않을까요?

추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.

(숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

room_count 컬럼은 카테고리에 있으면 안되는 컬럼입니다. room 테이블에 있어야 하는 컬럼입니다. 이유로는, "room_category, room_category_detail_ room_type" 테이블들은 서비스를 운영하는 "어드민" 즉, 서비스 관계자가 데이터를 만들어야 하는 테이블입니다. 이에 반해, room_count는 서비스를 사용하는 "사용자"가 입력해야 하는 값입니다. room_count가 "room_category, room_category_detail_ room_type" 테이블에 존재하게 된다면, 어드민이 데이터를 넣을 때 "해당 카테고리의 방을 만들 때는 x개의 방만 서비스하도록 해라"로 호스팅을 하는 사용자에게 강제하는 느낌이 강합니다.

위에 기능을 봤을때 2-5개/5-10개/10개-100개 정해진 항목들 중에 사용자가 선택하게 하는 것으로 이해했는데 잘못된 해석일까요?

네, 맞습니다. 사용자가 선택하는 데이터가 맞습니다. 제가 말씀드리고 싶은 것은 아래와 같습니다.

a. room_category 테이블은 서비스 관계자인 어드민이 자기의 서비스엔 3개의 종류인 "저택, 아파트, 부티크 호텔"이 있을 거라고 가정하고 3개의 데이터를 저장합니다. 이 "저택, 아파트, 부티크 호텔"에 대한 카테고리는 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다. b. room_category_detail 테이블은 서비스 관계자인 어드민이 "저택, 아파트, 호텔"에 대한 상세적인 카테고리를 저장합니다. 또한, 상세적인 카테고리를 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다. c. room_type 테이블은 서비스 관계자인 어드민이 "전체, 개인실, 다인실" 3개를 저장합니다. 또한, 해당 데이터도 에어비앤비를 가입하는 상요자가 저장하는 데이터가 아닙니다. 데이터를 저장하는 관점에서 봤을 때, room_category, room_category_detail, room_type 테이블은 사용자가 데이터를 저장하는 테이블이 아니고, 서비스 관계자인 어드민이 저장하는 느낌이 강합니다. 이로 인해, 세 테이블에 대해 데이터를 저장할 때는 어드민 사이트에서 서비스 관계자인 어드민이 저장하게 됩니다. 여기서 room_count를 room_category_detail 로 넣게 된다면, 어드민 사이트에서 어드민이 room_category_detail 데이터를 추가할 때에 input 태그로 데이터를 넣을 수 있게 된다는 얘기가 되는데, 이 경우 "특정 카테고리 상세 유형에서는 x개의 방을 서비스 제공하라"라고 강제하는 느낌이 강하다는 말이였습니다. 예를 들어, "부티크 호텔[room_category]-호텔[room_category_detail]" 과 "부티크 호텔-리조트" 2개의 room_category_detail이 있을 경우, room_category_detail 이 room_count에 있게 된다면 서비스 관계자인 어드민이 "호텔, 리조트"의 데이터를 등록할 때 room_count도 같이 등록하게 되어 해당 "room_category_detail "호텔, 리조트"를 제공할 때는 내가 이미 정해놓은 room_count에 맞게 제공해라." 라는 느낌이 됩니다. "부티크 호텔-호텔"과 "부티크 호텔-리조트"에 대해서 room_category_detail 테이블의 데이터는 2개가 존재하게 됩니다. room은 해당 room_category_detail에 연결되는 구조를 갖게 됩니다. 방이 5개가 있다고 가정하고, 방의 2개가 호텔이고, 리조트가 3개라고 연결됐다고 가정해봅니다. 여기서 room_count는 room_category_detail에 있는 컬럼이니 "호텔, 리조트"에 종속됩니다. 또한, 방을 만드는 사용자 입장에서는 room_count를 선택하여 설정할 수 없으니, 어드민 관계자가 이미 만들어 놓은 "호텔에서는 x개의 방을 제공하라"에 따라야 합니다. 사용자가 방의 개수를 선택할 수 없게 됩니다.

넵 room_category쪽 테이블은 모두 admin이 등록하는 데이터입니다 .
사용자는 어드민의 의도에 따라서 선택을 하는거죠

room_count도 일대다의 관계를 가지기 때문에 따로 빼야되지 않을까 생각합니다.

추가적으로 저희 서비스 로직에 따라 room_count는 category쪽 다른테이블에 붙을 수 도 있습니다.
그리고 room_count_id를 FK에서 nullable로 두면 입력되는 양식에서 아예 빠지게 할 수 있으니 강제로 x개의 방을 제공하라는 의무도 사라지지 않을까요?

다시한번 ERD 첨부드립니다.

memoer · 2022-06-16T04:51:56Z

추가사항) room_count(null) 컬럼은 서비스로직에 따라 room_category로 이동될 수도 있습니다.

(숙소에 총 방이 몇개입니까?) 관련 컬럼입니다.

room_count 컬럼은 카테고리에 있으면 안되는 컬럼입니다. room 테이블에 있어야 하는 컬럼입니다. 이유로는, "room_category, room_category_detail_ room_type" 테이블들은 서비스를 운영하는 "어드민" 즉, 서비스 관계자가 데이터를 만들어야 하는 테이블입니다. 이에 반해, room_count는 서비스를 사용하는 "사용자"가 입력해야 하는 값입니다. room_count가 "room_category, room_category_detail_ room_type" 테이블에 존재하게 된다면, 어드민이 데이터를 넣을 때 "해당 카테고리의 방을 만들 때는 x개의 방만 서비스하도록 해라"로 호스팅을 하는 사용자에게 강제하는 느낌이 강합니다.

위에 기능을 봤을때 2-5개/5-10개/10개-100개 정해진 항목들 중에 사용자가 선택하게 하는 것으로 이해했는데 잘못된 해석일까요?

네, 맞습니다. 사용자가 선택하는 데이터가 맞습니다. 제가 말씀드리고 싶은 것은 아래와 같습니다.
a. room_category 테이블은 서비스 관계자인 어드민이 자기의 서비스엔 3개의 종류인 "저택, 아파트, 부티크 호텔"이 있을 거라고 가정하고 3개의 데이터를 저장합니다. 이 "저택, 아파트, 부티크 호텔"에 대한 카테고리는 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다. b. room_category_detail 테이블은 서비스 관계자인 어드민이 "저택, 아파트, 호텔"에 대한 상세적인 카테고리를 저장합니다. 또한, 상세적인 카테고리를 에어비앤비를 가입하는 사용자가 저장하는 데이터가 아닙니다. c. room_type 테이블은 서비스 관계자인 어드민이 "전체, 개인실, 다인실" 3개를 저장합니다. 또한, 해당 데이터도 에어비앤비를 가입하는 상요자가 저장하는 데이터가 아닙니다. 데이터를 저장하는 관점에서 봤을 때, room_category, room_category_detail, room_type 테이블은 사용자가 데이터를 저장하는 테이블이 아니고, 서비스 관계자인 어드민이 저장하는 느낌이 강합니다. 이로 인해, 세 테이블에 대해 데이터를 저장할 때는 어드민 사이트에서 서비스 관계자인 어드민이 저장하게 됩니다. 여기서 room_count를 room_category_detail 로 넣게 된다면, 어드민 사이트에서 어드민이 room_category_detail 데이터를 추가할 때에 input 태그로 데이터를 넣을 수 있게 된다는 얘기가 되는데, 이 경우 "특정 카테고리 상세 유형에서는 x개의 방을 서비스 제공하라"라고 강제하는 느낌이 강하다는 말이였습니다. 예를 들어, "부티크 호텔[room_category]-호텔[room_category_detail]" 과 "부티크 호텔-리조트" 2개의 room_category_detail이 있을 경우, room_category_detail 이 room_count에 있게 된다면 서비스 관계자인 어드민이 "호텔, 리조트"의 데이터를 등록할 때 room_count도 같이 등록하게 되어 해당 "room_category_detail "호텔, 리조트"를 제공할 때는 내가 이미 정해놓은 room_count에 맞게 제공해라." 라는 느낌이 됩니다. "부티크 호텔-호텔"과 "부티크 호텔-리조트"에 대해서 room_category_detail 테이블의 데이터는 2개가 존재하게 됩니다. room은 해당 room_category_detail에 연결되는 구조를 갖게 됩니다. 방이 5개가 있다고 가정하고, 방의 2개가 호텔이고, 리조트가 3개라고 연결됐다고 가정해봅니다. 여기서 room_count는 room_category_detail에 있는 컬럼이니 "호텔, 리조트"에 종속됩니다. 또한, 방을 만드는 사용자 입장에서는 room_count를 선택하여 설정할 수 없으니, 어드민 관계자가 이미 만들어 놓은 "호텔에서는 x개의 방을 제공하라"에 따라야 합니다. 사용자가 방의 개수를 선택할 수 없게 됩니다.

넵 room_category쪽 테이블은 모두 admin이 등록하는 데이터입니다 . 사용자는 어드민의 의도에 따라서 선택을 하는거죠

room_count도 일대다의 관계를 가지기 때문에 따로 빼야되지 않을까 생각합니다.

추가적으로 저희 서비스 로직에 따라 room_count는 category쪽 다른테이블에 붙을 수 도 있습니다.

그리고 room_count_id를 FK에서 nullable로 두면 입력되는 양식에서 아예 빠지게 할 수 있으니 강제로 x개의 방을 제공하라는 의무도 사라지지 않을까요?

다시한번 ERD 첨부드립니다.

FK에서 nullable로 두면 입력되는 양식에서 아예 빠지게 할 수 있으니 강제성은 없앨 수 있다고 하더라도, 문제가 생깁니다.
room_count라는 데이터가 room_category 관련 테이블에 있으면 "특정 상위 카테고리 혹은 특정 하위 카테고리 혹은 특정 방의 타입"에 연결된 모든 방들의 방의 개수가 일괄적으로 변경됩니다. 이 경우에, 방마다 "개별"적으로 방의 개수 설정이 불가능합니다.

제안주신 ERD 설계의 흐름을 제가 이해한대로 적어보겠습니다.

room은 room_category_detail__room_type의 id를 갖고 있으니 그 쪽으로 연결됩니다.
room_category_detail__room_type에서 room_category_detail_id가 있으니 room_category_detail로 연결됩니다.
- 이때 "연결된" room_category_detail의 row는 단 한 개만 있습니다.
연결된 room_category_detail에서 room_count_id가 있으면 room_count 테이블에 연결됩니다. 여기서 해당 방의 개수를 확인할 수 있습니다.
여기서 문제가 됩니다. room이 10개가 있고, 10개의 room이 동일한 room_category_detail_id를 갖고 있다고 가정해봅니다. 방의 하위 유형을 "호텔"로 가정 하겠습니다. 이러면 room 10개의 하위 유형은 "호텔" 에 연결됩니다. 하지만, "호텔"은 room_category_detail 테이블에서 단 1개의 row만 갖고 있습니다. 즉, 방 10개는 room_category_detail의 row 1개와 연결됩니다. room_category_detail 테이블에서 room_count_id 를 통해 room_count에 접근하게 되고, 이 경우에 호텔인 하위 카테고리에 묶인 방 10개에 대해서 모두 방의 개수가 일괄적으로 설정됩니다.
room_category_detail 테이블에서 room_count_id를 null로 하여 room_count 테이블의 room_category_detail_id를 통해서 접근하는 법도 문제가 됩니다. room 10개가 "호텔" 인 하위 카테고리에 묶여져 있고, 이 "호텔"인 room_category_detail_id를 통하여 room_count 의 모든 row를 가져옵니다. 이렇게 가져온 room_count 의 row 들은 어떤 방과 연결되어 있는 지 알 수가 없습니다.

추가적으로, "room_count도 일대다의 관계를 가지기 때문에 따로 빼야되지 않을까 생각합니다."의 의도가 궁금합니다.

memoer · 2022-06-16T06:28:21Z

Slack 통해서 나온 결정사항들 남깁니다.

room_count는 room_table에 넣는다.
room_category_detail에 방의 개수를 입력해야 한다는 BOOLEAN 형태의 컬럼을 넣는다.

hoon25 · 2022-06-16T08:01:18Z

#26 (comment)

진하게 체크한 것으로 컬럼네임 가시는거 어떤가요?

room_category -> room_root_category(or)room_parent_category
room_category_detail -> room_leaf_category(or)room_child_category
room_type -> room_type
room_category_detail__room_type -> room_category(or)room_category_rule

memoer · 2022-06-16T08:01:58Z

#26 (comment)

진하게 체크한 것으로 컬럼네임 가시는거 어떤가요?

room_category -> room_root_category(or)room_parent_category room_category_detail -> room_leaf_category(or)room_child_category room_type -> room_type room_category_detail__room_type -> room_category(or)room_category_rule

오 좋습니다. 제가 맘에 드는 이름과 동일하게 생각하시는군요. 굳굳입니당

- 테이블 이름 변경 - room_category -> room_root_category - room_category_detail -> room_leaf_category - room_category_detail__room_type -> room_category - room_leaf_category에 컬럼 추가 `is_several_rooms` - 해당 카테고리를 선택한 방은 방의 개수를 설정해야 한다/안한다 여부 - room_price 테이블의 `weekly_price` 컬럼 이름 변경 -> `weekly_discount_price`

memoer · 2022-06-16T08:46:53Z

수정 반영본입니다.

memoer · 2022-06-16T13:52:32Z

DB 최종본

memoer · 2022-06-16T14:02:49Z

머지하겠습니다!

memoer added Type: Setting 개발 환경 설정 Size: X 변경/추가된 파일 10개 이하 labels Jun 15, 2022

auto-assign bot requested review from f-lab-michael and hoon25 June 15, 2022 08:15

auto-assign bot assigned memoer Jun 15, 2022

memoer force-pushed the chore/#3-DB_설계 branch 2 times, most recently from 39df288 to 69149b6 Compare June 15, 2022 10:06

chore(#3): DB 설계

4964a11

memoer force-pushed the chore/#3-DB_설계 branch from 69149b6 to 4964a11 Compare June 15, 2022 11:12

chore(#3): weekly_price->weekly_discount_price 컬럼 이름 변경

f526c7a

chore(#3): room_price 컬럼 weekly_price -> weekly_discount_price

c7b2219

chore(#3): DB 최종본 sql

2a85840

memoer changed the title ~~[#3] DB 설계 최종본~~ [#3] DB 설계 Version.0.1 Jun 16, 2022

memoer changed the title ~~[#3] DB 설계 Version.0.1~~ [#3] DB 설계 Version_0.1 Jun 16, 2022

memoer merged commit ec73904 into master Jun 16, 2022

memoer changed the title ~~[#3] DB 설계 Version_0.1~~ [#3] DB 설계 Version_1.0 Jun 16, 2022

memoer mentioned this pull request Jun 17, 2022

Revert "[#3] DB 설계 Version_1.0" #27

Merged

memoer deleted the chore/#3-DB_설계 branch June 17, 2022 05:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[#3] DB 설계 Version_1.0 #26

[#3] DB 설계 Version_1.0 #26

memoer commented Jun 15, 2022 •

edited

Loading

hoon25 commented Jun 15, 2022

memoer commented Jun 15, 2022 •

edited

Loading

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

room_category 관련 테이블들 변경 제안입니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

hoon25 commented Jun 16, 2022 •

edited

Loading

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

room_category 관련 테이블들 변경 제안입니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

memoer commented Jun 16, 2022 •

edited

Loading

room_category 관련 테이블들 변경 제안입니다.

hoon25 commented Jun 16, 2022

room_category 관련 테이블들 변경 제안입니다.

memoer commented Jun 16, 2022 •

edited

Loading

memoer commented Jun 16, 2022

hoon25 commented Jun 16, 2022

memoer commented Jun 16, 2022

memoer commented Jun 16, 2022 •

edited

Loading

memoer commented Jun 16, 2022

memoer commented Jun 16, 2022

[#3] DB 설계 Version_1.0 #26

[#3] DB 설계 Version_1.0 #26

Conversation

memoer commented Jun 15, 2022 • edited Loading

Description

COMMON

[TABLE] host

[TABLE] user

[TABLE] room

[TABLE] room_price

[TABLE] room_status

[TABLE] room_photo

[TABLE] room__room_faciltiy / room_facility / room_faciltiy_category

[TABLE] room_category / room_category_detail / room_type / room_category_detail__room_type

변경 사항

질문 사항

기타

(Optaionl) 어떻게 테스트하셨나요?

hoon25 commented Jun 15, 2022

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

room_category 관련 테이블들 변경 제안입니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

memoer commented Jun 15, 2022 • edited Loading

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

room_category 관련 테이블들 변경 제안입니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

hoon25 commented Jun 16, 2022 • edited Loading

Common 5.관련 질문입니다.

다대다 테이블에서 유니크 제약을 걸었습니다.

room_category 관련 테이블들 변경 제안입니다.

room_price 테이블 컬럼 이름 변경 제안입니다.

room_facility 관련 테이블들 이름 변경 제안입니다.

memoer commented Jun 16, 2022 • edited Loading

room_category 관련 테이블들 변경 제안입니다.

hoon25 commented Jun 16, 2022

room_category 관련 테이블들 변경 제안입니다.

memoer commented Jun 16, 2022 • edited Loading

memoer commented Jun 16, 2022

hoon25 commented Jun 16, 2022

memoer commented Jun 16, 2022

memoer commented Jun 16, 2022 • edited Loading

memoer commented Jun 16, 2022

memoer commented Jun 16, 2022

memoer commented Jun 15, 2022 •

edited

Loading

memoer commented Jun 15, 2022 •

edited

Loading

hoon25 commented Jun 16, 2022 •

edited

Loading

memoer commented Jun 16, 2022 •

edited

Loading

memoer commented Jun 16, 2022 •

edited

Loading

memoer commented Jun 16, 2022 •

edited

Loading