[Pre Onboarding-TIL]DB설계

연꽃·2021년 11월 14일
0

Pre Onboarding

목록 보기
9/12

과제의 소개

금융서비스의 계좌거래 API를 구현해야한다. 거래내역 조회, 입금, 출금, 송금 API를 구현하는 것이 이번 과제의 목표이다.

고민의 시작

거래내역 조회 API를 구현하는 것은 입금과 출금 그리고 송금에 대한 거래내역을 DB에서 불러오는 것이다. 그런데 여기서 고민을 했던 부분은 입금, 출금, 송금에 대한 테이블을 어떻게 설계할 것인가이다. 팀원들과 고민하면서 생각했던 방안은 크게 3가지이다.
1. 거래내역이라는 테이블한 개 만드는 것이다. 거래내역이라는 테이블에 입금, 출금 구분하는 필드를 생성한다. 그리고 송금의 경우에는 자기 참조를 통해서 조인(self join)하는 방안으로 생각하였다.
2. 입금과 출금 이라는 두 개의 테이블을 생성하는 것이다. 그리고 송금에대한 정보는 두 테이블이 일대일 관계를 가지도록 하여 외래키가 있는 경우에는 송금의 데이터가 저장된다. 즉 A가 B에게 송금을 하는 경우를 예로 들어보면, 입금 테이블에는 B의 입금이 저장되고 출금 테이블에는 A의 출금을 저장하는 것이다. 외래키가 없는 경우에는, 자신의 계좌에서 입금, 출금을 하는 것으로 표현을 할 수 있다고 생각했다.
3. 마지막으로 입금 테이블, 출금 테이블, 송금 테이블 세 개를 만드는 경우를 생각해 보았다. 그렇다면 같은 주제에 대해서 세개의 테이블을 구성하는 것이기 때문에 번거롭고 시간이 걸린다는 문제가 있을 수는 있겠지만 가장 보기 쉬울 수도 있다고 생각하였다.

각 방안에 대한 장단점

1번은 유저의 모든 거래내역(입금, 출금, 송금)을 조회할 때, 계좌 테이블과 거래내역 테이블을 각각 조인을 두번해서 해당 계좌의 모든 거래내역을 뽑아야한다. 그런데 두 테이블에 다르게 데이터가 있어 시간순서대로 다시 자바스크립트 코드로 정렬을 해야할 것이다. 대신 출금 거래내역 조회나, 입금 거래내역 조회는 필요한 테이블과 조인 하기만 하면 된다. 정리하면 전체 거래내역 조회할땐, 시간순으로 자바스크립트 코드로 정렬을 한번 해야한다. 입금, 출금 거래내역 조회할 땐 쿼리를 통해 정렬할 수 있다.

2번은 하나의 테이블에 모든 거래내역이 다 박혀있고 출금, 입금의 구분을 필드로 하기에 출금 거래내역 조회, 입금 거래내역 조회시 1번보단 시간이 더 걸릴 것이라 생각한다. 그러나 전체 조회시에는 시간순으로 정렬이 되어있어서 1번과 다르게 order by를 통해 쿼리로 정렬하여 데이터를 가져올수 있을 것이라 생각함. 정리하면 입금, 출금 각각의 거래내역 조회는 1번보단 성능이 좋지않다. 전체 거래내역 조회는 따로 자바스크립트 코드로 정렬해줄 필요가 없다.

3번은 거래내역 테이블간 관계가 필요없기에 한번에 보기 편하다. 그런데 하나의 주제에 대해서 세개의 테이블로 나누는 것이 데이터베이스의 무결성과 연관이 없을까?라는 고민을 하게 된다. 그리고 '송금 거래내역 조회'같은 기능은 없는데 굳이 테이블을 만들어야?하나라는 고민도 하게된다. 한눈에 보기 좋다.(거래내역 테이블간 관계가 없기에) 송금거래내역 조회가 요구사항에 없는데 굳이 테이블을 하나더 만들어야할까?

결정(2번)

한개의 테이블을 이용하면(1번 방안) 송금을 표현하는데 너무 복잡할 것이라 생각했다. 그리고 출금 거래내역 조회, 입금 거래내역 조회와 같은 기능에 대해서는 성능이 좋지 못할것이라 판단했다. 그렇기에 두개의 테이블(2번 방안)과 세개의 테이블(3번 방안)중 하나를 선택하기로 하였다. 나아가 세개의 테이블은 기능 요구사항과 맞지 않다 생각하였다. 그래서 두개의 테이블, 입금 테이블, 출금 테이블을 만들어서 두 테이블간 일대일 관계를 사용하여 송금을 표현하기로 하였다. 이 방법을 사용하면 전체 거래내역 조회시 자바스크립트 코드로 정렬을 해야한다. 쿼리로 정렬이 안된다. 그런 단점이 있지만 출금 거래내역 조회, 입금 거래내역 조회시에는 쿼리로 정렬이 되고, 한눈에 알아보기 쉬운 테이블 설계가 될것이라 생각했다.

최종 DB 스키마

profile
우물에서 자라나는 중

0개의 댓글