Today I Learned
날짜
2024년 2월 29일 목요일
내용
데이터베이스 계획 변경
다음 주에 시작될 스프린트의 공수와 일정을 확정짓는 플래닝미팅에 들어가기 전 마지막으로 PRD 기획 문서와 피그마를 체크했다. 기존에 열심히 고민하고 공부해서 이번에 추가될 데이터베이스 테이블을 짰는데, 몇가지 놓친 부분이 있어 크게 변경했다.
사용방식
기존 ERD 상으로, 위젯 테이블은 2개의 연관된 자식 테이블을 가지게 된다. 데이터 설정의 기준을 담는 테이블과 위젯에 포함되는 상품에 대한 테이블이다. 어제, 그제 열심히 고민한 부분은 후자였다. 하나의 상품이 위젯에 포함되는 갯수만큼 데이터를 만들 것인지, 상품 당 하나만 가지고 있을지. 전혀 생각하지 못한 부분이 뒤늦게 떠올랐고 의미없는 고민임을 알게됐다. 각 위젯은 데이터를 포함하기 위한 기준을 설정해야 한다. 예를 들어, 최근 이 상품을 구매한 고객에 정보의 최대 기준을 1일, 7일, 30일 등으로 가능하다. 똑같은 상품을 10일전에 김씨가 주문했어도 어떤 위젯에서는 최근 구매정보가 없다고 입력되야 하고 다른 위젯에서는 이 정보가 입력되야 한다. 같은 상품이라고 모두 정보가 같다는 보장이 없다는 의미이다. 따라서 각 상품은 위젯에 포함된 갯수만큼 데이터 정보를 가지고 있는게 맞았다. 황소 뒷걸음질 치다 쥐 잡은 꼴이네.
데이터를 설정하는 함수를 작성한다고 가정해보자. 최근 구매한 고객의 정보를 찾을 때 위에서 언급한대로 “기준”을 가지고 있어야 한다. 기존 데이터 구조에서는 이 떄
- 현재 생성한 위젯에 담길 상품에 관한 데이터 테이블과 연관된 “위젯 테이블”을 찾는다.
- 찾은 위젯 테이블과 연관된 “위젯에 데이터 설정 기준을 담는 테이블”을 찾는다.
- 원하는 설정이 담긴 필드를 찾는다.
의 과정을 겪는다. 고작 테이블이 3개만 추가되는데 너무 비효율적이다. 따라서 위젯에 데이터 설정 기준을 담는 테이블을 삭제하고 이것을 위젯 테이블에 json 필드로 추가해주었다. 이렇게 되면 관련된 위젯 테이블의 기준 필드에서 알맞은 데이터를 찾아 참고하면 된다.
jsonb 사용 이유
너무 많은 데이터 기준이 설정되게 되고, 디자인 설정을 위한 값도 많다보니 모두 필드로 설정하는 것에 부담이 있었다. 따라서 jsonb를 사용하기로 결정했다. jsonb가 json과 달리 가지는 장점은 내부의 key로 검색이 가능하다는 것이다.
{”도”:”경기도”, “시”:”화성시”,”동”:”장지동”} 이라는 dictionary 형태를 저장한다고 가정해보자.
json 타입으로 담긴 데이터는 저 통째로 하나의 문자열처럼 저장된다. 따라서 넣고 출력하는 과정에서 별도의 타입 변환이 필요없다. 다만 단점으로는 내부의 요소로 검색할 수 없다. json 타입 안에서 “도”의 값이 “충청도”인 경우는 검색할 수 없다. 모두 꺼내서 도가 무엇인지 직접 parsing하고 확인해야해서 검색상 불리하다.
이 단점을 해결한게 jsonb인데, “도”, “시”, “동”이 가지는 값으로 검색이 가능하다. 값을 탐색하는 것 뿐만아니라 특정 key가 있는 것(예를 들어, “구”라는 키를 가진 데이터)을 탐색할 수 있다.
다만 단점이 있는데, 들어가는 데이터의 타입을 변환처리해주어야 한다. 2024.02.29 형태의 datetime 타입이 포함되어 있다고 한다면, json에선 그냥 저장하면 된다. 알아서 string이 되기 때문이다. 하지만 jsonb에선 이떄 string으로 바꿔주어야 하고, 다시 조회할때도 마찬가지다. 검색에 장점이 있는 대신, 데이터 가공 과정이 별도로 필요하다는 의미이다.
위젯을 데이터 설정 기준이나 디자인 값으로 빠르게 검색할 이유가 없다면 굳이 jsonb를 사용해 데이터 변환처리를 할 이유가 없다. 따라서 json 타입을 사용하기로 결정했다.
회고
열심히 고민한다고 나름 짱구를 돌렸는데 아직 갈 길이 멀다.
