Closed junha-ahn closed 1 year ago
name
으로 통일 부탁드립니다seat_class.class
=> seat_class.name
id
로 선언 부탁드립니다round
가 필요한 정보입니까? 화면에서 특정일에 event_time 리스트를 요청한다면 start_datetime
으로 정렬해서 반환하면 문제없다고 생각합니다end_datetime
nullable start_date
, end_date
정보가 필요합니다 (1.1 ~ 1.5까지 오픈)지원하지 못할 것이라 판단하는 기능 리스트
네이밍
EVENT_TIME_TABLE
: 더 좋은 이름 없나요?AVAILABLE_SEAT
: AVAILABLE이 붙어야 하나요?
- 공연 제목등 모든 이름 정보는
name
으로 통일 부탁드립니다
- 완료
seat_class.class
=>seat_class.name
- 완료
- 모든 테이블의 pk는 테이블 명과 상관없이
id
로 선언 부탁드립니다
- 완료
round
가 필요한 정보입니까? 화면에서 특정일에 event_time 리스트를 요청한다면start_datetime
으로 정렬해서 반환하면 문제없다고 생각합니다
- round 정보는 쿼리의 count(*) where 구문으로 처리가능하다 판단하여 제거완료
end_datetime
nullable
- 공연의 종료 시간은 필요하고 not nullable이 옳습니다.
- Event 정보에
start_date
,end_date
정보가 필요합니다 (1.1 ~ 1.5까지 오픈)
- 완료
- 좌석의 다중 카테고리화 (1층-가/나구역, 2층-가/나구역)
- STAGE 에 대한 메타 정보를 담은 테이블을 만들어서 구현 가능 (WIP)
- 입석의 경우 한 클래스에 대해 1000명 제한을 두고 예매 가능하다 (싸이 흠뻑쇼 참고)
- [1,1] 좌석부터 [9999, 9999] 좌석까진 고정석이라고 가정. [0,0]을 일종의 상수로 가정하고 [0, 0] 좌석은 입석으로 간주하여 해당 기능 구현 가능. 좀 더 좋은 설계 WIP
- 좌석이 이벤트 타임 테이블에 종속되는 이유가 궁금합니다.
- 한 이벤트는 같은 좌석 정보를 공유할 것이라고 생각합니다.
- 더 나아가, 한 Stage는 같은 좌석 정보를 반영구적으로 공유합니다.
- 좌석 정보가 아니라 예매 정보가 타임 테이블과 관계되어야됨. 수정완료
- 한 Reservation Object는 여러 좌석을 예매 가능하다
- Mysql 에서 지원하는 JSON OBJ 데이터타입을 써서 한 컬럼에 복수의 [SEAT_IDs] 저장 가능하나 좀 더 좋은 설계 탐색중. JSON OBJ 컬럼의 WRITE 성능은 나쁘지 않음.
EVENT_TIME_TABLE
: 더 좋은 이름 없나요?
- 현재까진 없습니다.
AVAILABLE_SEAT
: AVAILABLE이 붙어야 하나요?
- AVAILABLE 접두사는 필요 없어 보입니다. 제거완료
Mysql 에서 지원하는 JSON OBJ 데이터타입을 써서 한 컬럼에 복수의 [SEAT_IDs] 저장 가능하나 좀 더 좋은 설계 탐색중. JSON OBJ 컬럼의 WRITE 성능은 나쁘지 않음.
이런 경우에도 JSON을 사용하는지 의문이지만, seat_id
는 Table로써 DB에 독립적으로 존재하는 Object입니다. (여러 디테일한 정보를 Json object 형식으로 저장하는건 상관없다고 생각합니다만...)
이때 Relation DB best practice는 외래키를 사용해 Reservation Table 또는 관계(연결) 테이블에 종속 관계를 등록시키는 것이라고 생각합니다.
JSON Object 형식은 Write 가 문제가 아니라, Read에 대한 검증이 필요해보입니다 (더 정확히는 조건문에 대한 처리가 어떻게 이루어지는지)
위와 같은 경우에 대한 JSON Object 레퍼런스가 있다면 참조 부탁드립니다
예약가능좌석이 공연장에 귀속이 되나요? 같은 공연장이여도 매공연마다 좌석배치가 바뀔수있고 좌석등급도 바뀔수있는데 이런상황에는 실제 같은 공연장이라도 다른 공연장ID를부여하나요?
@ParkJeongseop 실제로는 아래와 같은 정도의 작업 아닐까요?
매공연마다 좌석 배치가 바뀌거나, 좌석등급이 바뀌는 일이 발생하나요?
Mysql 에서 지원하는 JSON OBJ 데이터타입을 써서 한 컬럼에 복수의 [SEAT_IDs] 저장 가능하나 좀 더 좋은 설계 탐색중. JSON OBJ 컬럼의 WRITE 성능은 나쁘지 않음.
이런 경우에도 JSON을 사용하는지 의문이지만,
seat_id
는 Table로써 DB에 독립적으로 존재하는 Object입니다. (여러 디테일한 정보를 Json object 형식으로 저장하는건 상관없다고 생각합니다만...)이때 Relation DB best practice는 외래키를 사용해 Reservation Table 또는 관계(연결) 테이블에 종속 관계를 등록시키는 것이라고 생각합니다.
JSON Object 형식은 Write 가 문제가 아니라, Read에 대한 검증이 필요해보입니다 (더 정확히는 조건문에 대한 처리가 어떻게 이루어지는지)
- JSON Object 특정 Field가 외래키처럼 참조관계를 가질 수 있는지 (Cascade 등 여러 처리)
가능합니다. Array 타입은 불가능합니다.
- JSON Object 특정 Field가 Index 등록이 가능한지
가능합니다.
- JSON Object 특정 Field가 Join 조건에서 어떠한 성능을 가지는지 (2번과 밀접 - Join시 Index를 이용)
30%정도 느립니다.
위와 같은 경우에 대한 JSON Object 레퍼런스가 있다면 참조 부탁드립니다
예약가능좌석이 공연장에 귀속이 되나요? 같은 공연장이여도 매공연마다 좌석배치가 바뀔수있고 좌석등급도 바뀔수있는데 이런상황에는 실제 같은 공연장이라도 다른 공연장ID를부여하나요?
유연한 좌석 구조를 갖도록 설계를 변경했습니다.
명시적인 PK가 없는 경우 InnoDB는 그 값을 생성합니다. 비록 사용자에게는 노출되지 않는다 하더라도. FROM
- 여러 STAGE를 가지는 상위 객체(A홀, B홀 - 서울예술회관) 구현 후 필요한 모든 객체에 연결 부탁드립니다.
구현완료
- NOT NULL 여부 노출 바랍니다.
수정완료
- 관계테이블 등 모든 테이블은 PK(=ID)를 명시적으로 선언해주십시오.
수정완료
- ERD에서 외래키는 PK 바로 아래 배치 바랍니다 (읽기 편하고 보통 그렇게 합니다)
erdcloud에서 우선순위 조정 기능이 불가능하여 수정 불가.
- 관계 테이블 명명 규칙 보통 어떻게 하는지 레퍼런스 부탁드립니다
here 두 테이블의 이름을 합치는 방식을 주로 사용. News Table + Reader Table => NewsReader Table 이런식으로 예를 들 수 있음. 접미사 MAP
을 붙여서 relationship이 있다는 것을 의도적으로 표현하기도 함. 이 편이 가독성이 더 좋아서 이 방식을 사용.
- USE CASE 정의 부탁드립니다. (화면, API, Query 중심)
작성중.
회관은 공연과 공연장에 종속되는 관계가 아니라 반대인걸로 생각됩니다.
좌석 태그 테이블 tag에서 다른 이름으로 변경 부탁드립니다.
아래와 같은 입석 시나리오의 경우 STAGE_SEAT가 2000개(row:null,col:null
) 추가되야하나요?
가구역(태그)
나구역(태그)
개발 시나리오
# init table
3. 조회 API 테스트 & 구현 (각각 테이블의 getOne, getList)
4. POST /reservation API에 좌석 예매 적용
Description
예매에 좌석 기능을 고려해주세요
To do
기능 요구사항 (모든 기능을 구현할 필요는 없습니다)
Test Checklist