좌석‐등급 매핑 테이블 설계에 관하여

개요

At Ticket 프로그램의 데이터 베이스를 설계 중, 각 공연의 각 좌석에, 등급을 지정해줄 필요성을 느꼈습니다.

공연과 좌석과 등급의 관계는 이렇습니다.

1. 각 좌석에는 등급이 매겨져 있어야 합니다.  
왜냐하면 등급에 따라 좌석의 가격이 달라지기 때문입니다.    

2. 좌석의 위치가 같은 공연장의 같은 위치의 자리여도, 공연에 따라 등급이 다르게 매겨질 수가 있습니다.  
따라서 공연별로 각 좌석의 등급은 다르게 매겨져야 합니다.

공연별로 각 좌석의 등급 정보를 저장하기 위해,
ShowSheat 라는 테이블을 만들어서 좌석과 등급의 매핑 정보를 저장하도록 테이블을 만들었습니다.

매핑 테이블 생성

테이블의 구조는 다음과 같았습니다.

showid	등급	좌석 Id
1	A	1
1	A	2

좌석 1개당 일일이 등급 매핑한 정보를 저장한다.

좌석 Id 1개당 등급 정보를 1개씩 저장하도록 만들었습니다.

문제점

멘토님이 테이블 구조를 보더니 지적을 해주셨습니다.
예약되지도 않은 좌석의 데이터를 저장하는 것은 너무 비효율적이라고 말입니다.

조금 생각을 해보니, 예를 들어,
상영관의 좌석이 300개라 치면 하루에 공연이 4개만 있다고 쳐도, 일주일치에 30 0x 4 x 7 = 8400 라는 많은 행을 필요로 하게 됩니다.

일주일에 8400행인데, 한달 두달 N달이 지나게 되면 더욱 엄청난 수의 데이터를 예약하지도 않은 좌석의 저장을 위하여 정보 저장에 쓰게 될 것입니다.

그래서 예약된 좌석 데이터만 저장하도록 설계를 바꾸었습니다.

매핑 테이블 수정

showid	등급	좌석 Id 리스트
1	A	1,2,3,4,5,6,7
1	B	8,9,10,11

공연의 등급별로 예약된 좌석만 리스트로 저장한다.

예약된 좌석 정보만 저장하게 변경함으로써
쓸데없는 데이터를 저장하느라 DB저장 공간을 낭비할 필요가 없어졌습니다.

[수정] 설계 수정

테스트에 사용할 데이터를 집어넣다가 구조적으로 석연치않은 점을 발견했습니다.

상품 상세 페이지에서 공연 일자마다 남은 좌석들을 보여줄 필요가 있는데,  
이때 서로 다른 일자(서로 다른 showId)마다 같은 맵핑 데이터를 넣어줄 필요가 있습니다.    

문제는 서로 다른 공연일지라도 같은 공연장이라면 맵핑 데이터가 대부분 같다는 것이였지요.
중복 데이터들을 잔뜩 넣어야 하는 일이 발생합니다.

물론 예외적으로 같은 공연장 좌석이 공연이 서로 다른 일자에 다른 가격이 적용되는 일도 있을 수 있지만 (비수기와 성수기의 가격이 다른 것 처럼)
예외적인 사항은 따로 테이블을 관리해주는 편이 중복 데이터를 더 많이 줄일 수 있을 거라고 판단하였습니다.

따라서 저희는 아래처럼 showId 대신 productId와 hallId를 추가로 맵핑하여,
서로 다른 일자마다 추가해주어야 하는 맵핑 데이터 중복을 제거할 수 있었습니다.