#16 상영일정 테이블, 명세 작성

상영일정의 설계는 CGV를 참고해서 진행했다.

상영관(ex. 3관)에 소속되며 날짜와 분단위까지 24시간제로 저장되고 현재 남은 좌석수가 출력된다.

📌 설계

실제 영화관을 가정하여 설계하려함

1. 영화관이 아닌 상영관에 소속됨 영화관 <- 상영관 <- 상영 일정 이런 모양으로 참조 -> 상영관과 참조 맺을 외래키 필요

2. 시간의 경우 영화의 시작시간과 종료시간을 저장하기로함

3. 튜플의 생성시간, 업데이트 시간도 남기기로 결정

4. 보통 영화를 고르고 일정을 확인하는 것을 고려해 영화 엔티티도 참조하기로 결정 -> 영화와 참조 맺을 외래키 필요

그리고 남은 좌석수의 경우 두가지 옵션을 고려했는데

첫번째, 상영일정 자체에 남은좌석수를 저장
상영일정을 참조하는 좌석 엔티티를 따로 구현할 생각인데 좌석이 판매될 때마다 상영일정의 남은 좌석수를 업데이트 하는방법

두번째, 좌석 엔티티에 상태를 읽어와서 카운트된 남은 좌석수를 나타내는 방법

첫번째 방법의 경우 반정규화에 해당하고 좌석 테이블에서 변화가 일어날 때마다
상영일정 테이블을 업데이트 해야하는 기능이 추가로 필요하며

두번째 방법의 경우 매번 좌석 테이블을 조회해야 하므로 성능에 많은 부담을 줄 것이라는 생각이 들어서 고민했다.

하지만 두번째 방법을 사용하기로 했는데 결정한 이유는

1. 정규화를 유지할 수 있음
   좌석 테이블에 무언가 문제가 발생했을 때 발생할 수 있는 데이터 불일치를 예방할 수 있을거라는 생각 첫번째 방법은 서비스를 통해 좌석수를 업데이트 하므로좌석 테이블에서 발생하게될 에러에 대한 대응 구현을 하기가 어렵다고 생각함

2. 첫번째 방법은 코드를 객체지향적이지 못한 방향으로 유도할 지도 모른다는 생각
   좌석수를 업데이트 해주는 메서드를 따로 구현해야 하므로 두번째 방법의 경우 검색 메서드를 실행하면 끝이지만 첫번째의 경우 좌석의 상태가 업데이트 될 때마다
   상영일정 서비스에 있는 기능을 호출하여 좌석수를 업데이트 해야하는데
   이는 복잡성을 증가시키고 좌석 기능 유지보수시 상영일정 서비스에도 영향을 미치게 되므로 좋은 코드를 만들기 어렵다고 생각함

3. 서버의 성능만 받쳐준다면 두번째 방법의 단점이 상쇄됨

위 세가지 이유가 더해져서 두번째 방법인 좌석수를 검색하여 나타내기로 하였다.

📌 테이블 작성

설계한 대로 애트리뷰트들을 만들었다.
튜플 id, 소속 상영관, 상영 영화, 시작종료시간, 튜플의 생성과 업데이트 시간 순으로 작성했다.

📌 시퀀스 다이어그램 작성

CRUD 네가지로 작성했으며 검색의 경우 상영관과 날짜 선택후에만 시작시간이 현재 시간 이후인 상영일정만 검색하도록 제한을 둘 것이라 딱 CRUD 네가지로 정리가 되었다.

📌 API 명세

시퀀스에 그린대로 구현할 Api들의 명세를 해보았다.
Http 메서드는 api의 성격에 맞게 결정하였고 공통 Response를 이용하여
반환될 json을 명시했다.

📌 후기

참조관계까지 있으므로 이후 구현단계에서 착오를 줄이고 빠르게 진행하기 위해서
충분히 고민을 하면서 설계를 진행했다.

그리고 시퀀스 다이어그램이 복잡해보인다는 조언을 들어서 이전보다도 더 간결하게 작성을 하려 노력했다.

어린아이가 보더라도 이해할 수 잇도록
보는 사람의 입장을 더 고려해서 작성을 해야겠다.