맨 처음 티켓팅을 주제로 잡고, 필요한 구성요소들을 생각했을 때 크게 네 가지로 나뉘었었다.
[유저] / [이벤트] / [티켓] / [리뷰]
유저나 리뷰는 자주 다뤘던 내용이라 금방 넘어갔지만, 공연과 티켓에 어떤 내용을 담을 것인지, 어떻게 설정할 것인지에 대한 회의가 계속 되었다.
이벤트 ( 뮤지컬, 콘서트, 전시회, 스포츠 등.. )
- 카테고리 : String
- 포스터 이미지 링크 : String
- 제목 : String
- 장소 - String( 서울 국립 극장 )
- [좋아요] 수 : Int
- 평점 ( 1~5 ) : Float
- 현재 상태 ( 예매 대기 / 예매 가능 / 판매 종료 ) : Enum
- 이벤트 시작일 : DATE
- 이벤트 종료일 : DATE (현재 상태 판별)
- 예매 가능 좌석 갯수 : Int
- 등급별 가격 : Int
- 이벤트 정보 : String
처음엔 위와 같이 예매에 대한 구체적인 고민 없이 간략화 하여 진행하려고 했었다.
이벤트 시작일-종료일을 기준으로 현재상태를 확인하고, 예매 가능 자석 갯수를 지정하여 예매가 진행될 때 마다 1씩 감소하도록. 등급별 가격도 일정.
티켓
- 고유아이디 - 티켓 등록 번호
- 이벤트 ID - 이벤트 이름
- 관람일시
- 가격
- 예매일 ( CreatedDate )
- 좌석번호 ( 선착순 번호 )
티켓에도 간단한 정보만 담아놓고 시작하였다.
하지만 '일단 시작하자' 라고 생각했다가 중간 기능이 추가되면 온갖 애로사항이 꽃핀다는 것을 겪었기 때문에 정말 이대로 시작할지, 추가할 내용이나 정책을 조금 더 고민해보기로 했다.
1. 일자별로 예매할 수 있는 티켓이 달라야 한다.
- 기존 방법으론 일자 구분 없이 '남은 좌석'으로 비교했었다.
- 그럼 어떻게 날짜별로 나눌 것인가 ???
1-1. 리스트를 만들어 날짜별 잔여 좌석수를 갖기?
ex) [0] : 153 , [1] : 252, [2] : 3 ...
1-2. 날짜 별 좌석 테이블을 생성하여 관리하기
ex) 좌석 테이블( 이벤트ID / 날짜 / 남은 좌석 )
2. 매 이벤트(공연)마다 장소와 좌석의 크기를 지정해주어야 하는 문제
- 구조상 문제는 없지만 같은 장소를 여러번 사용 할 때 매번 값을 직접 입력해줘야 한다는 것이 문제가 있을 수 있고, 장소에 대한 내용은 자주 변경되는 내용이 아니므로 별도의 테이블을 생성하여 맵핑하기로 결정.
3. 좌석 등급과 가격에 대한 고민
- 좌석의 등급과 가격은 매 공연마다 값이 달라질 수 있는 유동적인 요소라서 어떻게 구성할지 고민이 있었다.
3-1. 이벤트 테이블에 각 등급 별 가격 정보를 저장하기 ( R석, S석, 일반석 )
-> 단, 이벤트 테이블의 내용이 너무 잡다해진다는 것이 단점
3-2. 가격 정보를 표시할 별도의 테이블 구성
ex) 가격 ( 이벤트ID / R석 가격 / S석 가격 / A석 가격 )
3-3. 좌석의 등급을 미리 나누지 말고 이벤트 마다 별개로 가격 필드를 생성할 수 있도록 테이블 구성
ex) 가격 ( 이벤트ID / 등급 / 가격 )
실제로 가격 테이블을 구성한다면 3-3 의 방법이 가장 확장성이 좋을 것 같았지만, 리스트 형식으로 값을 가져와 테이블을 자동 생성하는 과정을 구현하는 것의 작업량이 많아질 것으로 우려되어 편의상 좌석 등급은 3가지만 고려하는 것으로 결정했다.
4. 위의 내용을 반영하여 좌석 테이블 재구성
이벤트 아이디를 외래키로 사용하며 날짜별로 남은 좌석 수를 표시하도록 설정하였다.
5. 티켓 테이블의 재구성
마지막으로 티켓 테이블을 재구성하였다.
티켓을 예매하기 위해 사용자는 이벤트Id, 날짜, 좌석등급, 좌석번호 를 설정하여 전송하게 되고, DB에서 위 내용과 일치하는 값이 있는지 1차적으로 확인. 2차적으로 유효한 날짜와 등급별 잔여 자석을 확인하여 예매 성공 여부를 설정할 수 있도록 하였다!
초기 구상보다 관리할 테이블이 많아져 관계성 설정과 영속성 전파에 많은 고민이 필요해질 것 같다.
하지만 '확장성'을 기준으로 고민해보는 시간을 갖고, 다소 돌아가는 것 같지만 합리적으로 구현할 수 있도록 노력하였다.
완성된 ERD 의 웅장해진 모습ㅎ
