개발자

관계형 DB 설계 시 카테고리 같은 것은 어떻게 저장하시나요?

2022년 11월 14일조회 1,265

안녕하세요. 이번에 기능을 구현하다가 문득 궁금해져서 질문납깁니다. 요구사항은 게시글에 카테고리가 추가되고, 해당 카테고리에 따른 게시글을 모아보는 페이지와 네비게이션을 생성하는 작업입니다. 네비게이션에서 게시글 카테고리를 클릭하면 해당 카테고리의 게시물들을 보여주는게 주 목적입니다. 게시글이 post로 MySQL에 저장되고 있는데 여기에 category라는 값을 추가하려고 하는데요. 질문은 카테고리를 어떤 형태로 저장하는게 좋은가 입니다. 기존 코드와 DB 설계 (다른 유사한 테이블)를 살펴보면 category라는 값을 숫자로 저장시키고 사용하는 서비스에서 각 숫자에 맞는 설명?타입을 선언하는 방식이더라구요. 예를 들면, DB에 category = 1로 저장된 post는 사용하는 서비스 (서버)에서 enum 또는 const로 선언해서 category = 1이면 PostCategory.Article 타입을 같는 형태입니다. 이후 사용자가 보게되는 프론트에서도 유사하게 category에 따른 카피를 보여주고 있어요. 특이사항이 있다면, 프론트에서 category에 따라 보여지는 카피는 수시로 바뀔 수 있을 것 같아요. 예를 들면, category = 1인 Article 타입이라면 카피 문구가 “논문”이라고 했을때, 나중에 카피가 “기사” 같은 것으로 바뀔 수 있어요. 이렇게 category 처럼 데이터의 속성이 잘 안바뀌는 값은 숫자로 정의하고 사용하는 위치마다 그에 맞게 타입을 선언하는게 좋을까요? 아니면 category를 DB에 만들때 문자열 형태로하고 “article”이라는 값을 바로 DB에 저장하는게 좋을까요?

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.
profile picture
익명님의 질문

답변 1

손정현님의 프로필 사진

우선 질문 주신 상황을 제대로 이해했는지 헷갈려서 아래의 가정을 하고 답변을 드리겠습니다 - 기존 posts 테이블에 INT 또는 TINYINT 타입인 category를 추가한다 - DB에서 꺼낸 post 데이터의 category는 단순 숫자이며 (1, 2, 3), 사용하는 서비스에서 단순 숫자에 맞는 타입을 명시한다. ex) category가 1일때 type은 article - 프론트에서도 마찬가지로 category가 1일때 type이 article이고, article에 맞는 카피를 보여준다 - category 자체는 안 바뀌지만, 카피는 바뀔 수 있다. ex) category = 1이면 무조건 article이다. 다만, article일때 "논문"을 보여주다가 나중에 "기사"로 바뀔 수 있다 이런 상황에 답은 없는 것 같지만, 저라면 기존 코드를 작성하셨던 개발자분을 붙잡고 설계할 때 왜 그렇게 했는지 여쭤볼 것 같네요. 만약 해당 작업자분이 안계신다면, category에 string을 그대로 넣어도 되는지가 궁금하시겠죠. 한번 살펴볼까요 우선 category에 string 그대로 넣었을때 이점을 생각해보겠습니다. 1. category에 숫자가 있는것보다, category의 이름이 들어가 있는게 더 명시적이다 2. 불필요한 카테고리 타입 선언 코드를 줄 일 수 있다 그럼 구현하려면 어떻게 해야할까요? 단순히 posts의 category에 string으로 넣는게 진정 효율적일까요? 우선 제가 생각했을때 비효율적인 부분은 아래와 같습니다. - 같은 데이터가 중복됨 - posts가 많아지면 많아질수록 category를 저장하는 메모리도 계속 발생함. 더군다나 string이라면 기존 TINYINT 같은 것보다 메모리도 많이 먹음 위 문제를 해결하려면 어떻게 하는게 좋을까요? 저라면 PostCategories라는 테이블을 새로 만들 것 같네요. 그리고 posts 테이블에는 postCategoryId를 추가할 것 같아요. category의 수도 최소화하고 중복을 제거하는 거죠. 이렇게하면 또 다른 고려사항이 생깁니다. - 기존 posts 조회 로직에 JOIN이 필요할 수 도 있음. - 위 테이블을 만드는데 시간이 듦 여기서 장기적으로 봤을때 더 관리하기 용이한 방법은 PostCategories 테이블을 만드는 것이라고 생각합니다. 하지만 현재 작업 시간이 별로 없다면 저라면 기존 DB 설계 방식 (TINYINT)을 유지할 것 같아요. 이유는: 1. 장기적 관점을 생각하는 것보다 현재 기능을 빠르게 개발하는게 먼저라고 생각됨 2. 기존 설계 방식에 다른 동료 개발자 분들이 더 익숙함 (더 빨리 코드를 이해할 가능성 높음) 3. 기존 설계 방식에 다른 고려사항이 있을 수 있음 (이것 때문에 이전 작업자에게 설계 이유를 여쭤보는게 좋은데, 안 계신다면 고민이 좀 될 것 같아요) 사실 저도 DB 설계 경험이 많지는 않아서 순전히 "내가 작업을 한다면?"이라는 관점으로 접근해봤구요. 다른 좋은 방법이 있거나, 다른 답변자 분들이 더 좋은 답변을 달아주실것 같아서 참고 정도만 해주시면 될 것 같습니다 :)

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

목록으로
키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!