RDB 테이블 설계에 대해 질문드립니다.

Question

안녕하세요서비스에서 신고 기능을 구현하려고 하는데 RDB 테이블 설계 과정에서 조언이 필요하여 질문 드립니다.현재는 상품, 상품 후기에 대해서 신고 기능을 만들 예정이고, 한 명의 회원은 같은 대상에 대해 중복 신고가 불가능하게 하고자 합니다(1회만 가능).이를 위해 신고 이력을 테이블로 구성하여 관리하려 하는데 추후 신고 대상을 확대(회원 간 채팅 메시지 신고 등)할 가능성이 있습니다.이 경우, 대상마다 신고 테이블을 각각 새로 만들기보다는 하나의 공통된 신고 테이블에서 모든 신고를 처리하는 방식이 더 좋을까요?전자의 경우,product_report(product_id, reporter_id), review_report(review_id, reporter_id)와 같이 2개의 테이블을 구성하는 것이고 신고 대상이 확장되면 신고 대상의 신고 테이블을 새로 만들어야 합니다.후자의 경우,report(target_id, target_type, reporter_id) 와 같이 구성하는 것이고 신고 대상이 확대되더라도 target_type만 추가로 구성하면 되므로 테이블을 새로 만들 필요는 없지만 유니크 인덱스 키 크기가 증가하고 전자에 비해 복잡성이 약간 증가한다고 생각합니다.관련 기능이나 유사한 기능에 대한 설계 경험있는 분들의 조언 부탁드리겠습니다.항상 친절히 답변해주시는 오키 개발자님들께 감사드립니다 (_ _)!

장독깨기 · Answer

후자의 경우 외래키를 걸지 못 합니다.전자로 하는 것이 좋겠습니다.

우엥 · Answer

실제로는 고려해야할 다른것들이 많은걸로 압니다만 알려주신 내용만으로 답변 드리자면 저는 이렇게 해결한 경험이 있습니다혹시 target_id만으로 type이 분류되지는 않으신가요? 예를 들어 product_id는 p_1, review_id는 r_1 이런 형태라고 한다면 애초에 target_id만 가지고 있어도 이 신고가 어떤 유형의 신고인지까지 파악이 가능하겠죠그럼 테이블을 추가할 필요도 없어지고 되려 report 테이블마저도 target_id, reporter_id 두개의 컬럼으로 줄일수가 있어집니다저는 신입이라 제 의견이 참고하시기에 많이 부족할겁니다만 일전에 sns를 만들때 즐겨찾기, 추천 등등의 기능을 구현할때 동일한 고민을 했었고, 그때 저는 target_id를 파싱해서 게시글의 형태인지, 유저의 형태인지에 따라 구분하는 방식을 통해 테이블이나 컬럼을 간소화하면서 구현했던 기억이 나서 말씀드려봅니다! 아마 실제로는 파싱하는데 발생하는 비용과 db간소화를 통해 얻는 이득을 비교하는 등 여러가지 저울질을 해봐야하지 않을까 싶습니다

MungGaeDev · Answer

후자처럼 묶을 경우,A유형 신고의 처리방식과, B타입 신고의 처리방식이 다를 경우 개발 피로도가 좀 더 높아질 수 있습니다.

나땅 · Answer

게시판 타입 다르다고 여러개로 안빼는것처럼 신고테이블을 하나만 빼는게 좋아보입니다

RDB 테이블 설계에 대해 질문드립니다.

4개의 답변

Q&A 목록