내가 프론트엔드에서 보는 데이터베이스

꽤 많은 입력 필드를 가진 폼이 있는 경우, 혹은 장문의 텍스트를 넣어야 하는 경우에 "임시 저장" 기능을 제공하는 것은 여러모로 도움이 된다. 해당 페이지에 접근한 사용자의 권한이나 성격에 따라 이 저장을 user 아래에 둘 수도 있고, authority나 service 아래에 둘 수 있다. 이에 따라 저장하는 방식도 직접 db에 저장할 수도 로컬 스토리지를 이용하여 사용자 개인(user)의 pc에 저장할 수도 있다.

그래서 프론트엔드인 내가 DB를 바라보는 관점은 데이터 저장소로 해당 기능에 얼마나 유효한가...하는 점이다.

이런 명세를 받은 적이 있다.

1. 입력한 폼의 내용을 임시 저장할 수 있다.
2. 임시 저장은 여러번 가능하다.
3. 2의 내역을 조회하여 그 중 어느 하나를 불러 올 수 있다. (이어서 작성하기 기능) 또한 삭제할 수도 있다.
4. 완료를 클릭하면, 입력한 폼을 DB에 푸시한다.
5. 4의 내역은 조회할 수 있으며, 3과 똑같이 이 중 하나를 들고 입력 폼 페이지로 이동할 수 있다. (FORK 기능) 또한 삭제할 수 있다.

폼의 입력값을 메모리에서 넣어놓는 패턴을 사용한다면 내 생각에 저장소는 3개의 계층을 형성한다.

- 로컬 (메모리 또는 스토리지)
- DB1 : 임시로 저장한 내역
- DB2 : 완료하여 저장한 내역

만약 상태를 두어서 저장한 방식이 임시인지 완료인지를 구분하려 한다면 DB에 테이블을 2개를 둘 필요는 없다.

그럼에도 왜 임시로 저장한 내역과 완료하여 저장한 내역을 별도의 DB로 보는가 하면, 우선 임시로 저장하는 내역 역시 삭제할 수 있다. 로직이 간단하면 분기가 쉽지만 상태는 늘어나기 쉽고 그러면 로직에는 틈이 생길 수 있다. 둘째로 나중에 테이블을 확장할 때 문제가 되지 않을까 하는 점이다. 굳이 클래스가 아니라도 객체에 무언가 프로퍼티를 붙이는 것 하나만으로도 객체의 성격이 바뀐다. 맞지 않는 옷을 더덕더덕 붙이다보면 본래의 성격도 잃어버린다.

쉬운 비교군이라면 장바구니와 찜하기가 있을 것이다. 둘 다 상품을 임시로 어딘가에 넣어둘 수 있고, 주문 리스트로 불러올 수 있다. 그렇지만 성격이 다르다. 찜하기는 가격을 합산할 필요가 없지만 장바구니는 주문 전 가격을 보기 위해 합산할 필요가 있다. 또한 배송등의 수수료 계산이 필요하며, 무게 정보를 활용해야 할 수 있고, 판매자를 그루핑할 필요가 있다. 찜하기는 주문과 동시에 DB에서 삭제할 필요가 없지만 장바구니는 정책에 따라서는 삭제해야 한다.

DB를 합치면 목적에 따른 분리가 어려워서 저장소가 기능에 유효할 수도 유효하지 않을 수도 있는 슈뢰딩거씨의 고양이 같은 느낌의 모습이 상황에 따라 발생할 수 있다.

스키마가 완전히 동일한 테이블을 2개를 둘 필요가 있는가...하는 점은 관리의 효율성으로 볼 때 별로 일 수도 있겠지만, 그건 기능을 떼고 생각하는 게 아닐까 싶다. 스키마는 같지만 활용하는 목적이 달라 기능에 차이가 생기고 또 무엇보다 로직으로 CRUD를 분리하려는 접근은 안전하지 않을 것이다.