지역 및 카테고리 도메인 설계 이슈

[ssibongee]

• 현재 확장성을 고려하여 카테고리를 열거 타입이 아닌 별도의 테이블로 만들어서 구성
  • 카테고리가 정말 그렇게 확장성이 높은 도메인인가
  • 지금 게시글 조회할 때마다 필수적으로 불러읽어와야하는 카테고리의 비효율성을 없애기 위해 캐싱을 적용해서 사용하고 있음
  • 차라리 이렇게 자주 빈번하게 동시에 조회되고 결합도가 높은 속성이라면 캐싱을 적용해서 성능개선을 하는 것이 아니라 하나의 테이블에서 관리하는 것이 맞지 않은가
• 지역 같은 경우는 오히려 별도의 테이블로서 관리되어야 할 것 같은데 내부 컬럼으로 관리가 되어짐
  • 결국 사용자와 게시글 테이블에 지역에 관련된 컬럼이 중복적으로 나타나게 되는데 이러한 부분은 정규화를 통해서 별도의 테이블로 분리하는 것이 좋지 않을까
  • 지역은 단순 시도, 시군구, 읍면동 이외에도 다양한 정보들을 가질 수 있을 것 같은데 이를 활용하기 위해서라도 별도의 도메인으로 분리하는 것이 맞지 않을까
  • 충분히 다른 테이블로 분리하더라도 인덱스를 적용할 수 있을 것 같은데 이 경우 외래키를 인덱스로 사용하는 경우와 경우와 거리적으로 가까운 위치의 지역들을 어떻게 클러스터로 묶어서 데이터베이스에 저장할지 인덱스를 어떻게 활용하는 것이 좋을지를 고려해야함

[ssibongee]

• 지역 같은 경우 내부에 별도의 테이블로 관리할 수도 있지만 도로교통부의 도로명주소 공공 API를 활용하는 방법도 존재한다.
• 이 경우 특정 API에 애플리케이션이 강하게 결합되는 문제를 발생시킬 수 있지만 별도의 지역관련 테이블을 관리할 필요가 없어진다.