[설계] Tag 테이블 리팩토링 및 Tag 검색 방안

현재 상황

예비부부, 플래너, 포트폴리오, 아이템에서 태그를 참조하고 있습니다. 기본적으로 N:M 관계이기 때문에 현재는 중간테이블을 두어 태그 테이블과 연결하는 방식을 사용합니다.

유저는 주어진 태그뿐만 아니라 자신이 직접 태그를 추가할 수 있고, 추가한 태그로도 검색이 가능합니다.

문제점

현재 MVP 기능 ERD만 그렸는데도 테이블이 많아지고, 기능이 추가됨에 따라 중간 테이블도 많아져 데이터 구조가 복잡해질 수 있다는 단점이 존재합니다.

 

해결 방안

1. 중간 테이블을 하나로 통합하고, boolean 값을 통해 태그 중간 테이블을 관리

- table_id (long)
- is_customer (bool)
- is_planner (bool)
- is_porfolio (bool)
- is_item (bool)
- tag_type (string)

장점 : 하나의 테이블로 모든 태그를 관리할 수 있기 때문에 설계가 간단해진다
단점 : 기능이 추가될 때마다 테이블을 모두 수정해야 하기 때문에 확장성이 좋지 않다.

현재 저희는 MVP 개발 상태이고, 추가 기능이 개발될 수 있는 가능성을 열어놓고 있기 때문에 해당 해결 방안은 적절하지 않아 보였습니다.

2. 중간 테이블 없이 String으로 태그를 받아 관리하기

인스타그램 등이 사용하고 있는 방식이며, 해당 방식을 사용하면 유저 커스텀 태그로도 검색 가능

장점 : 중간 테이블이 필요 없어 테이블 구조 간소화 / 유저 커스텀 태그로도 손쉽게 검색 가능
단점 : 검색을 위해서는 elastic search를 이용해야 하는데 현재 사용자가 없는 저희 서비스 상으로는 오버스펙에 가깝습니다.

 

멘토링

일단 커스텀 태그를 사용하려고 해서 더 복잡해지는 것 같다는 의견을 주셨습니다. 차라리 서비스 런칭 시 최대한 태그를 많이 준비해서 커스텀 태그 없이 저희가 제공한 태그만으로 EQUALS나 LIKE 검색을 하는 것이 나아보입니다.

 

결론

문자열 방식을 사용하되 검색의 경우 elastic search 대신 그냥 문자열 검색(ex. '친절한' -> '친절')로 구현합니다.

 

추가 의견

개인적으로는 File 리팩토링에서 사용 예정인 방식도 좋아보입니다.

Long target_tag_id; // 중간 테이블 id
Long tag_id             // 태그 id
Long target_id        //  기능 id (planner, portfolio, customer, item)
String target_type   // 어떤 기능인지 표시