[DB/RDBMS] 계층형 태그 테이블 관리

배경

사실 DB 설계를 제대로 해본 경험이 없다. 그래서 인턴을 할 때도 이렇게 구성해도 괜찮은지에 대한 피드백은 받지 못했었다.
최근에 다시 개발 감을 익히고 뭔가 만들고 싶다는 생각이 들어서 여러 프로젝트를 구상해봤다.
그 중에서 하나를 골랐는데, 해당 프로젝트 할 때 계층형으로 태그를 저장 및 사용하는 기능이 필요하다고 생각했다.
근데 앞서 말했듯 난 DB 설계를 제대로 해본 경험이 없어서 열심히 찾아봤다.

 

프로젝트에서 태그의 의미와 용도

- 태그는 정보를 추가하기 위한 수단으로 사용하고, 사용자가 임의로 관리가 쉬워야한다. (추가, 수정, 삭제)

- 카테고리도 태그로 나타낼지에 대해서도 고민을 하고 있다. (카테고리에 대한 정의와 정확한 이름이 필요하다고 느꼈다. 방금)

- 계층형 구조에서 하나를 선택했을 때, 바로 그의 자식에 해당하는 태그가 보여야한다. 즉, 선택한 태그에 대해 직계 자손을 찾기가 쉬워야한다.

- parent는 child를 부르지만, child가 parent를 부르는 경우는 거의 없다. (부른다가 과연 맞는 표현인가..)

- 내역을 추가할 때, 선택된 태그들이 저장된다. (만약 태그별로 테이블이 많다면... 그만큼 관계 표현을 위한 column이 추가된다.)

 

기본 정보

우선 카테고리가 있다. 그리고 카테고리에 속하는 태그를 만들어야하고, 태그 안에 태그가 종속되어있기도 해야한다.

처음 생각했던 테이블 구조는 위와 같았다. (나름 최근에 빅데이터 보안이라는 과목을 수강하면서 1정규화..2정규화 등등을 고려하면서 단순하게 짜려고 노력한 것...)

근데 아무리 생각해도 카테고리와 태그를 위해서 테이블을 3개나 사용하는게 맞나? 라는 고민을 하게 되었다.

그래서 보통 사실상 같은 컬럼을 가진 계층 관계는 어떻게 정의하고 설계하는지 찾아봤다.

참고: https://journey-to-serendipity.tistory.com/39

 

 

찾아보니 다양한 구조가 있었고, 내가 후보에 둔 구조는 2개였다.

Adjacency List

하나의 테이블에서 관리할 수 있는 구조였다. parent_id 라는 컬럼 추가하고 부모 관계를 테이블에 추가한 것으로 가장 단순하고 이해가 쉬웠다. 

단점으로는 tag의 부모를 찾기 위해 깊이 탐색을 해서 성능은 좋지 않다는 점

Closure Table

이번엔 태그를 하나의 테이블로 정보를 입력하고, 태그 관계를 따로 정의한다. 

깊이가 깊더라도 성능은 다른 구조에 비해 좋다고 한다.

단점은 태그 관계를 나타내기 위해 어쨌거나 테이블이 추가된다는 점...

 

세미결론

아무래도 관련 카테고리가 선택되었다면, 해당 카테고리에 해당하는 태그와 그 계층구조를 전부 보내고, 프론트에서 처리하는게 낫다고 생각이 들었다. 

그리고 태그를 생성하는 것은 사용자의 몫이지만, 프로젝트를 하면서 태그가 불필요하게 많이 생성될 가능성은 낮다고 보았다.

우선은 Closure Table을 사용하는 방안으로 DB 설계를 진행해보기로 했다. (선택 이유는 성능이 좋다고 하기 때문에)

일의 순서가 참 중요하다.. 사용자 플로우를 머리로만 생각하고 설계하려니까 자꾸 꼬이는 것 같아서 사용자 플로우를 먼저 정리하고 와이어프레임을 대충 짜보고 다시 설계를 진행해야겠다..

 

결론(추가)

태그가 무한대로 많아질 상황이 많지 않아 특정 태그의 자손을 그때그때 가져오는게 부담이 없다는 생각이 들었다.

그래서 태그 관계를 한번에 가져오기보다는 선택된 태그의 자손을 그때그때 가져오는 것으로 결정했다.

그러려면 closure table말고 adjacency list가 더 나아보였다. 

왜냐면 직계 자손만 그때그때 가져오려고 하기 때문에!!

그리고 계층이 최대 3단계라서 깊이깊이 찾을 염려가 없다고 생각했다.