한 테이블

Question

나는 다음과 같은 테이블이 있습니다 - 게시물 - 파일 - 이벤트 - 문서

모든 후, 파일, 이벤트, 문서

댓글을 가질 수 있습니다.

, 왜 이것에 대한 더 나은 데이터베이스 스키마 무엇입니까?

첫 번째 솔루션

• 코멘트 테이블 (comment_id, author_id, 주석)의 관계 (posts_comments (post_id를, comment_id를 만들 수
• 4 표), files_comments (FILE_ID, comment_id), events_comments (EVENT_ID, comment_id) documents_comments (가 document_ID, comment_id))

번째 해결

,

• 코멘트 테이블 (comment_id, author_id, 코멘트)
• items_comments (comment_id, PARENT_TYPE (ENUM [ '포스트', '파일', '이벤트', '문서'), PARENT_ID)

더 나은 해결책은 무엇입니까? 아니면 두 가지 중 어느 것을 사용해야합니까?

Answer 1

는 하나의 코멘트 테이블을 필요/원하는에 대한 진짜 이유가있을 수 있습니다 데이터베이스 정규화에 부합. 예를 들어 특정 사용자의 모든 댓글을 보는 것이 더 간단 해집니다. 또한 모든 주석을 통한 검색은 더 쉬울 것입니다 (하나의 테이블에 하나의 FTS 인덱스를 넣으면 완료됩니다). 단일 테이블의 주석을 유지하는 강력한 이유가없는 경우 한편

는 가능한 세 번째 (오히려 명백한) 솔루션이있다.

각 항목 (포스트, 이벤트, 파일, 문서)에 대한 별도의 코멘트 테이블을 만듭니다. RI 관계는 그 상황에서 정의하고 설명하는 것이 매우 간단합니다. 또한 임시 쿼리를 자주 입력하는 경우 더 간단해질 수 있습니다. 예를 들면

select * from documents d left join doc_comments c 
          on d.id = c.docid 
          where d.id=42; 

이 중 어느 것도 해당 상황에 적절하지 않거나 중요 할 수는 없지만 고려해 볼 가치가 있습니다.

하나의 추가 생각 : OP의 두 솔루션 모두 다지간 관계를 정의하는 "느낌"을 가지고 있습니다 (예 : 의견이 여러 항목에 속할 수 있음). 그것이 원하는 상황이 아니라고 가정하면, 적절한 고유 인덱스로 막을 수는 있지만 여전히 ... 그것이 초기 혼란을 가져올 수있는 것처럼 보입니다.

Answer 2

첫 번째 해결 방법을 선호합니다. SQL 문은 더 간단합니다. 그리고 내 생각에 그건 더

Answer 3

완벽을 기하기 위해, 다른 가능성을 언급해야합니다 - 상속 (일명.일반화 또는 (하위) 범주 계층 구조) : 당신은 당신이 원하는 경우 (1 이름을 편집하여 파일 이름 파일을 변경해야하므로