[클룸] 클래스의 세션별로 데이터 관리하기 - 기술적 의사결정

문제상황

클래스 예약 시스템을 구축하면서 예상치 못한 문제에 직면했다.

초기에는 클래스의 일자와 시간을 클래스 테이블에 배열로 넣고, 예약된 인원을 체크하기 위해

클래스 테이블에 예약 수 count 필드를 넣어서 사용자가 예약을 하면 그인원 수 만큼 count가 올라가고,

남은자리는 클래스의 최대 인원에서 예약인원 수를 빼서 보여주고 있었다.

 

그러나 우리가 간과하고 있는 중요한 부분이 있었다.

클래스의 하나의 일자에 여러 시간대가 있다면, 각 회차별로 남은 자리를 별도로 체크해야 할 필요성이 생기는데, 이를 고려하지 못하고 있었던 것이다. 또한 지금의 테이블 설계는 일자에 시간이 어떻게 종속되고 있는지 전혀 관리하지 못하고 있다

이 문제를 해결하기 위해 팀원들과 의견을 나누었고, 두 가지 주요 의견으로 좁혀졌다.

제안된 의견

1. 객체 형태로 관리하기 (클래스 - 일자 - 회차)
장점👍
- 직관적이다
클래스 하나를 선택했을 때, 그 안에 포함된 일자와 회차까지 한 번에 조회할 수 있다. 

단점😰
- 관계형 데이터베이스에 맞지 않는 설계
	
2. 날짜, 시간 테이블을 따로 만들기
장점👍
- 데이터 무결성
각 테이블이 독립적이고 관계를 통해 연결되어 있기 때문에, 데이터 무결성을 유지하면서 관리하기가 용이하다.

- 확장성
구조를 변경할 필요 없이 새로운 관계를 정의하거나 기존 관계를 수정할 수 있다
ex) 만약 클래스의 회차별로 정원을 따로 관리하는 기능을 추가해야 할 때 갈아엎을 필요없이 테이블을 추가, 수정하면 된다. 

단점😰
- 조회 성능 저하
각 세션의 정보를 조회하기 위해서 여러 테이블을 조인해야한다. 따라서 조회 성능이 하락한다.

- 기존 api 함수 다 갈아엎어야함.. 😂

 

결정한 방식

날짜, 시간 테이블을 따로 만들기

우리가 지금까지 json-server나 firebase같은 NoSQL 형식의 DB를 사용했기 때문에 1번 방식에 익숙하고, supabase에서도 객체를 담는식으로 구현할 수도 있겠지만, 관계형 DB인 supabase를 사용하기로 결정한 만큼 그에 맞는 설계를 하는 것이 맞다고 판단했다.

 

다음 글에서는 데이터베이스 설계와 로직 구현에 대해서 작성해보도록 하겠다.

 

다음글

https://seopport-u.tistory.com/87

[클룸] 클래스의 세션별로 데이터 관리하기 - 설계