[BACKLOG] 좌석 예매 기능 구현

[junha-ahn]

Description

예매에 좌석 기능을 고려해주세요

To do

기능 요구사항 (모든 기능을 구현할 필요는 없습니다)

• 이미 예약된 좌석은 선택 불가능
• 좌석은 A클래스, B클래스 등으로 구분할 수 있으며, 다른 금액을 가질 수 있다
• 입석(스탠딩)이 존재한다 (limit: xx)
  • 입석간에도 등급이 존재한다
  • 싸이 흠뻑쇼
• 단체 예약이 가능하다
• 한 공연장(좌석 구조)에서 여러 Event가 열릴 수 있다.
  • xx예술회관을 생각해보자. 해당 예술회관에는 A홀, B홀이 존재한다. A홀과 B홀은 각각 다른 좌석 구조를 가진다. 하지만 A홀에서 열리는 서로 다른 Event는 모두 A홀의 좌석 구조를 공유한다.
• Event는 같은 날 여러번 오픈 가능하다 (1시 1회차 공연, 2시 2회차 공연)
• Event는 특정 기간동안 오픈 가능하다
  • 캣츠 내한공연은 2023.01.20 (금) ~ 2023.03.12 (일) 동안 세종대극장에서 상영한다.
• 위와 같은 기능을 모두 지정한다면 프로세스는 다음과 같다
  • Event 선택 => 관람일 선택 => 회차 선택 => 좌석 선택 => 결제(생략) => 예매 완료
  • 나훈아 티켓팅 방법
• 좌석은 Display에 표현 가능해야 한다

Test Checklist

[bohblue2]

[junha-ahn]

1. 공연 제목등 모든 이름 정보는 name으로 통일 부탁드립니다
2. seat_class.class => seat_class.name
3. 모든 테이블의 pk는 테이블 명과 상관없이 id로 선언 부탁드립니다
4. round가 필요한 정보입니까? 화면에서 특정일에 event_time 리스트를 요청한다면 start_datetime으로 정렬해서 반환하면 문제없다고 생각합니다
5. end_datetime nullable
6. Event 정보에 start_date, end_date 정보가 필요합니다 (1.1 ~ 1.5까지 오픈)

지원하지 못할 것이라 판단하는 기능 리스트

1. 좌석의 다중 카테고리화 (1층-가/나구역, 2층-가/나구역)
2. 입석의 경우 한 클래스에 대해 1000명 제한을 두고 예매 가능하다 (싸이 흠뻑쇼 참고)
3. 좌석이 이벤트 타임 테이블에 종속되는 이유가 궁금합니다.
   • 한 이벤트는 같은 좌석 정보를 공유할 것이라고 생각합니다.
   • 더 나아가, 한 Stage는 같은 좌석 정보를 반영구적으로 공유합니다.
4. 한 Reservation Object는 여러 좌석을 예매 가능하다

네이밍

1. EVENT_TIME_TABLE: 더 좋은 이름 없나요?
2. AVAILABLE_SEAT: AVAILABLE이 붙어야 하나요?

[bohblue2]

1. 공연 제목등 모든 이름 정보는 name으로 통일 부탁드립니다
   • 완료
2. seat_class.class => seat_class.name
   • 완료
3. 모든 테이블의 pk는 테이블 명과 상관없이 id로 선언 부탁드립니다
   • 완료
4. round가 필요한 정보입니까? 화면에서 특정일에 event_time 리스트를 요청한다면 start_datetime으로 정렬해서 반환하면 문제없다고 생각합니다
   • round 정보는 쿼리의 count(*) where 구문으로 처리가능하다 판단하여 제거완료
5. end_datetime nullable
   • 공연의 종료 시간은 필요하고 not nullable이 옳습니다.
6. Event 정보에 start_date, end_date 정보가 필요합니다 (1.1 ~ 1.5까지 오픈)
   • 완료

지원하지 못할 것이라 판단하는 기능 리스트

1. 좌석의 다중 카테고리화 (1층-가/나구역, 2층-가/나구역)
   • STAGE 에 대한 메타 정보를 담은 테이블을 만들어서 구현 가능 (WIP)
2. 입석의 경우 한 클래스에 대해 1000명 제한을 두고 예매 가능하다 (싸이 흠뻑쇼 참고)
   • [1,1] 좌석부터 [9999, 9999] 좌석까진 고정석이라고 가정. [0,0]을 일종의 상수로 가정하고 [0, 0] 좌석은 입석으로 간주하여 해당 기능 구현 가능. 좀 더 좋은 설계 WIP
3. 좌석이 이벤트 타임 테이블에 종속되는 이유가 궁금합니다.
   • 한 이벤트는 같은 좌석 정보를 공유할 것이라고 생각합니다.
   • 더 나아가, 한 Stage는 같은 좌석 정보를 반영구적으로 공유합니다.
   • 좌석 정보가 아니라 예매 정보가 타임 테이블과 관계되어야됨. 수정완료
4. 한 Reservation Object는 여러 좌석을 예매 가능하다
   • Mysql 에서 지원하는 JSON OBJ 데이터타입을 써서 한 컬럼에 복수의 [SEAT_IDs] 저장 가능하나 좀 더 좋은 설계 탐색중. JSON OBJ 컬럼의 WRITE 성능은 나쁘지 않음.

네이밍

1. EVENT_TIME_TABLE: 더 좋은 이름 없나요?

   • 현재까진 없습니다.

2. AVAILABLE_SEAT: AVAILABLE이 붙어야 하나요?

   • AVAILABLE 접두사는 필요 없어 보입니다. 제거완료

[junha-ahn]

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에 대한 검증이 필요해보입니다 (더 정확히는 조건문에 대한 처리가 어떻게 이루어지는지)

1. JSON Object 특정 Field가 외래키처럼 참조관계를 가질 수 있는지 (Cascade 등 여러 처리)
2. JSON Object 특정 Field가 Index 등록이 가능한지
3. JSON Object 특정 Field가 Join 조건에서 어떠한 성능을 가지는지 (2번과 밀접 - Join시 Index를 이용)

위와 같은 경우에 대한 JSON Object 레퍼런스가 있다면 참조 부탁드립니다

[ParkJeongseop]

예약가능좌석이 공연장에 귀속이 되나요? 같은 공연장이여도 매공연마다 좌석배치가 바뀔수있고 좌석등급도 바뀔수있는데 이런상황에는 실제 같은 공연장이라도 다른 공연장ID를부여하나요?

[junha-ahn]

@ParkJeongseop 실제로는 아래와 같은 정도의 작업 아닐까요?

1. Stage에 종속된 Seat정보를 바탕으로 공연장의 좌석 정보를 노출한다
2. 매 Event Time Table 마다 unavailable_seat 를 관리자가 선택할 수 있게 한다 (다만 구현하지 않을 예정으로 DB설계)

매공연마다 좌석 배치가 바뀌거나, 좌석등급이 바뀌는 일이 발생하나요?

• 만약 그렇다면, 해당 기능도 구현에 포함할지 논의가 필요해보입니다.

[bohblue2]

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에 대한 검증이 필요해보입니다 (더 정확히는 조건문에 대한 처리가 어떻게 이루어지는지)

1. JSON Object 특정 Field가 외래키처럼 참조관계를 가질 수 있는지 (Cascade 등 여러 처리)

가능합니다. Array 타입은 불가능합니다.

2. JSON Object 특정 Field가 Index 등록이 가능한지

가능합니다.

3. JSON Object 특정 Field가 Join 조건에서 어떠한 성능을 가지는지 (2번과 밀접 - Join시 Index를 이용)

30%정도 느립니다.

위와 같은 경우에 대한 JSON Object 레퍼런스가 있다면 참조 부탁드립니다

[bohblue2]

예약가능좌석이 공연장에 귀속이 되나요? 같은 공연장이여도 매공연마다 좌석배치가 바뀔수있고 좌석등급도 바뀔수있는데 이런상황에는 실제 같은 공연장이라도 다른 공연장ID를부여하나요?

유연한 좌석 구조를 갖도록 설계를 변경했습니다.

[bohblue2]

[junha-ahn]

1. 여러 STAGE를 가지는 상위 객체(A홀, B홀 - 서울예술회관) 구현 후 필요한 모든 객체에 연결 부탁드립니다.
2. NOT NULL 여부 노출 바랍니다.
3. 관계테이블 등 모든 테이블은 PK(=ID)를 명시적으로 선언해주십시요

명시적인 PK가 없는 경우 InnoDB는 그 값을 생성합니다. 비록 사용자에게는 노출되지 않는다 하더라도. FROM

4. ERD에서 외래키는 PK 바로 아래 배치 바랍니다 (읽기 편하고 보통 그렇게 합니다)
5. 관계 테이블 명명 규칙 보통 어떻게 하는지 레퍼런스 부탁드립니다
6. USE CASE 정의 부탁드립니다. (화면, API, Query 중심)

[bohblue2]

1. 여러 STAGE를 가지는 상위 객체(A홀, B홀 - 서울예술회관) 구현 후 필요한 모든 객체에 연결 부탁드립니다.

구현완료

2. NOT NULL 여부 노출 바랍니다.

수정완료

3. 관계테이블 등 모든 테이블은 PK(=ID)를 명시적으로 선언해주십시오.

수정완료

4. ERD에서 외래키는 PK 바로 아래 배치 바랍니다 (읽기 편하고 보통 그렇게 합니다)

erdcloud에서 우선순위 조정 기능이 불가능하여 수정 불가.

5. 관계 테이블 명명 규칙 보통 어떻게 하는지 레퍼런스 부탁드립니다

here 두 테이블의 이름을 합치는 방식을 주로 사용. News Table + Reader Table => NewsReader Table 이런식으로 예를 들 수 있음. 접미사 MAP을 붙여서 relationship이 있다는 것을 의도적으로 표현하기도 함. 이 편이 가독성이 더 좋아서 이 방식을 사용.

6. USE CASE 정의 부탁드립니다. (화면, API, Query 중심)

작성중.

[junha-ahn]

1. 회관은 공연과 공연장에 종속되는 관계가 아니라 반대인걸로 생각됩니다.

   • Event, Stage, 좌석Tag가 HALL_ID를 1:N 외래키로 가지는 구조가 맞는것 같습니다

2. 좌석 태그 테이블 tag에서 다른 이름으로 변경 부탁드립니다.

3. 아래와 같은 입석 시나리오의 경우 STAGE_SEAT가 2000개(row:null,col:null) 추가되야하나요?

가구역(태그)

• CLASS A 입석 500석
• CLASS B 입석 500석

나구역(태그)

• CLASS A 입석 500석
• CLASS B 입석 500석

[junha-ahn]

[junha-ahn]

개발 시나리오

1. Entity Object 구현 (~9.3)
2. Mock Data setup SQL 작성
   • 많은 데이터는 필요 없습니다, 개발 중 API 테스트가 가능한 정도로 setup
   • 3개정도의 stage와 3개 정도의 이벤트, 3개정도의 다른 seat 구조
   • 필요 테이블: Hall, Stage, Event, Event_time_table, stage_seat, seat_class, available_seat
   • 태그 관련은 필요하지 않습니다.

     
     # init table

insert data...

3. 조회 API 테스트 & 구현 (각각 테이블의 getOne, getList)
4. POST /reservation API에 좌석 예매 적용