投稿した質問数 21

0

안녕하세요 ! 질문 너무 잘해주셨어요 !

질문해 주신 내용에 대해 답변드려볼게요 ~

"만약 신고사유가 객관식 다운드롭형태일때는 테이블을 따로 분리하는건가요??"

-> 말씀하신 대로 신고사유가 고정된 선택지로 제공되는 경우라면 신고사유 테이블을 별도로 분리하는 방식이 일반적이에요 !

이렇게 하면 신고 테이블에서는 신고사유 테이블의 ID를 외래키로 참조하는 형태가 되죠 ~

다만 꼭 테이블을 분리해야만 하는 건 아니에요!

신고사유의 종류가 적고 거의 변하지 않는다면 ENUM 타입이나 코드값으로 신고 테이블에 직접 저장하는 방법도 있어요 ~

예를 들어 신고사유를 "SPAM", "ABUSE", "AD" 이런 식으로 문자열이나 숫자 코드로 저장하는 거죠:)

정리하자면 신고사유가 자주 추가되거나 변경될 가능성이 있다면 별도 테이블로 분리하는 게 유지보수에 유리하고, 거의 고정된 값이라면 ENUM이나 코드값으로 처리해도 충분해요 !

추가로 궁금하신 점 있으시면 언제든 편하게 질문 남겨주세요~~

0

안녕하세요, 인프런 AI 인턴입니다. Teo님.

신고사유가 객관식 형태로 제공된다면, 일반적으로 신고사유 테이블을 별도로 분리하는 것이 올바른 설계 방법입니다. 이렇게 하는 이유는 다음과 같습니다:

1. 유지보수의 용이성: 신고 사유의 목록은 시간이 지나면서 변경될 수 있습니다. 예를 들어, 사유를 추가하거나 삭제하게 되는 경우, 별도로 분리된 테이블을 관리하는 것이 더 효율적입니다.

2. 데이터 정규화: 신고사유를 독립적인 테이블로 분리함으로써 데이터 중복을 최소화하고, 데이터 정합성을 유지할 수 있습니다. 이는 데이터베이스의 성능 및 무결성을 개선하는 데 기여합니다.

3. 확장성: 향후 다양한 신고 유형이 추가되거나 다른 언어로의 번역이 필요할 경우, 분리된 테이블을 통해 쉽게 확장할 수 있습니다.

각 신고 항목이 신고사유 테이블의 외래키를 통해 참조되도록 설계하면, 신고시스템의 정확성을 높일 수 있습니다.

유사한 주제를 다룬 게시물이 있어 연결해드립니다:
- 데이터베이스에서 정규화와 외래키 활용하기

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.