Лучшее решение для таблицы комментариев для нескольких типов контента

Question

В настоящее время я разрабатываю таблицу комментариев для сайта, который я создаю. Пользователи смогут загружать изображения, связывать видео и добавлять аудиофайлы в профиль.

Каждый из этих типов контента должен быть комментируемым. Теперь мне интересно, как лучше к этому подойти.

Мои текущие параметры:

1. чтобы иметь одну большую таблицу комментариев и таблицы ссылок для каждого типа контента (comments_videos, ...) с comment_id и _id.

2. чтобы комментарии разделялись по типу контента, для которого они. Таким образом, каждый тип контента будет иметь свою собственную таблицу комментариев с комментариями для этого типа.

Answer 1

Я не согласен с принятым ответом. Как бы вы проверили целостность данных таким образом? у вас могут быть поврежденные идентификаторы, если ваше приложение работает неправильно. Кроме того, вы никогда не должны полагаться только на приложение для обеспечения целостности данных. Кроме того, вы думали, как каскадировать ваши удаления в таблицу комментариев, когда вы удаляете какие-либо медиа?

Если вы хотите сохранить все комментарии в одной таблице, вам нужно два дополнительных столбца, один для идентификатора носителя и один для типа носителя. Затем вы можете написать триггер для обеспечения целостности вашей комбинации носителей (id, type).

Кто-нибудь может сказать лучше? * Кен 1005 *

Answer 2

Для одного комментария на файл создайте одну таблицу, подобную этой:

Comments
CommentID     int identity/auto generate Primary key
CommentType   char(1) or tinyint/byte etc FK to CommentTypes table
Comment       string
CreateDate    date/time
CreateUserID  int  FK

в других таблицах используйте это так:

Video
VideoID
Video...
CommentID  FK

Audio
AudioID
Audio...
CommentID  FK

Для нескольких комментариев на файл создайте одну таблицу, подобную этой:

Comments
CommentID     int identity/auto generate Primary key
MediaID       int --no explicit FK, but can join to VideoID,AudioID etc on this
CommentType   char(1) or tinyint/byte etc FK to CommentTypes table
Comment       string
CreateDate    date/time
CreateUserID  int  FK

в других таблицах используйте это так:

Video
VideoID    int identity/auto generate Primary key, joins to Comments.MediaID
Video...


Audio
AudioID    int identity/auto generate Primary key joins to Comments.MediaID
Audio...

Answer 3

Лично я мог бы пойти на первый вариант.Соберите все комментарии в одной таблице с типом комментария, который бы идентифицировал тип комментария.

Это позволит вам загружать комментарии независимо от реального контента, а затем использовать что-то вроде отображаемого контента (видео / adiou), который может быть загружен по запросу.позволяют упростить запрос комментариев к записи .

Answer 4

Честно говоря, ни один из этих двух вариантов не имеет значения. Вы ожидаете, что данный фрагмент контента любого типа (аудио / видео / и т. Д.) Может иметь несколько комментариев. Каждый комментарий является эксклюзивным для одного контента. (Например, комментарий может относиться только к одному типу контента / один и тот же комментарий не может появляться как на видео, так и на картинке). Пока это правда, здесь нет большой разницы, только мелкие детали.

Я бы просто взял одну таблицу содержания. Если вы хотите, вы можете создать представления для каждого, которые показывают все комментарии для данного типа содержимого.