search

jvnlee / catch-dining

맛집 검색 및 예약 서비스
0 stars 0 forks source link

Seat Entity Re-design #36

Open jvnlee opened 4 months ago

jvnlee commented 4 months ago

개요

Seat 엔티티의 설계 방식을 변경하여 데이터 관리 효율 및 유지보수성을 개선

 

문제 상황

Seat 엔티티에 날짜와 시간 데이터(availableDate과 availableTime)가 포함되어 있는 기존 구조가 DB의 Seat 테이블을 지나치게 방대하게 만드는 문제가 있음.

특정 옵션의 좌석 1가지에 대해 1 x 14 (2주) x n (예약 가능 시간대의 수)

만약 n이 6이면 이미 좌석 1가지에 대해 84개의 레코드가 생겨남

한 식당 안에 또 다른 옵션의 좌석이 있을 수 있고, 식당 또한 무수히 많을 수 있다는 것을 고려하면 레코드가 기하급수적으로 증가함

또한 서비스 정책 상 예약 가능 기간(2주)이 있기 때문에 가변적인 날짜 데이터를 주기적으로 벌크 업데이트해야 하는 오버헤드가 존재함.

SeatService의 updatePastDates()를 통해 매일 새벽 3시마다 @Modifying으로 벌크 업데이트 쿼리를 날리고 있음.

 

개선 방안

날짜와 시간 데이터를 Seat 엔티티로부터 분리시켜 SeatSchedule이라는 새로운 엔티티에 편입시킴.

→ 2주치의 날짜와 각 날짜에 대한 24개의 예약 가능 시간대를 저장 (14 x 24 = 168개의 고정된 수의 레코드)

 

하루가 지날 때마다 기존처럼 Seat 테이블 전체를 업데이트 하는 것이 아니라 SeatSchedule 테이블을 업데이트함

→ 지나간 날짜에 해당하는 레코드를 DELETE 또는 사용 안함 처리하고, 새로운 날짜에 해당하는 레코드를 INSERT함.

 

Seat 엔티티와 SeatSchedule 엔티티는 다대다(N:M) 연관관계를 지니므로, 이를 중간에서 1:N, M:1 로 풀어낼 수 있는 ReservableSeat 엔티티를 새로 추가함.

→ 기존에 Seat가 가지고 있던 좌석 수량(quantity) 정보를 ReservableSeat에 넣음.

→ 이제 주요 기능인 예약을 할 때는 ReservableSeat 엔티티를 사용하고, 그 외에 좌석이 가진 옵션을 조회하는 것은 Seat 엔티티를 통해, 좌석이 가질 수 있는 예약 가능 날짜와 시간대 조회는 SeatSchedule 엔티티를 통해서 함.

Cyma-s commented 4 months ago

기존의 스키마 구조와 다른 스키마를 채택해주셨네요! 생각해보면 좋을 몇 가지 질문을 남겨두겠습니다 :)

  1. 해당 스키마의 장점과 단점은 무엇이라고 생각하시나요?
  2. 사용자의 이전 예약 기록을 남겨두어야 하기 때문에, DELETE 를 할 수는 없을 것 같아요. 지나간 날짜의 레코드를 남겨두게 된다면, 시간이 지날수록 데이터가 많아지지 않을까요? Seat Schedule 과 더불어 Reservable seat 테이블 레코드도 늘어날테니 저장되는 데이터가 2배가 될 것 같아요 🤔
  3. 현재 이슈 내용에서는 reservation 스키마와 관련된 부분이 언급되지 않았는데, reservation 스키마는 이전과 동일한가요?
  4. 제시해주신 스키마 구조에서도 seat schedule 을 벌크 업데이트하게 될 것 같은데, 이 부분에 대해서는 어떻게 생각하세요?