Проблема проектирования базы данных

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

Должен ли я хранить отдельные таблицы для комментариев, например (Picture_comments & videos_comments)
ИЛИ ЖЕ
я должен сохранить одну таблицу для комментариев и других таблиц сопоставления, таких как (picture_comment_mapping & video_comment_mapping).

Какой из них будет лучше подходить и почему?

подробность
Подход 1:

user
     id
     name

Picture
     id
     link
video
     id
     link

comment_video
     id
     user_id
     video_id
     comment
comment_picture
     id
     user_id
     picture_id
     comment

Подход 2:

user
     id
     name

picture
     id
     link
video
     id
     link

comment
     id
     user_id
     comment

comment_picture_mapping
     id
     comment_id
     picture_id
comment_video_mapping
     id
     comment_id
     video_id

Какой из них лучше подходит и почему?

Источник

4 ответа

Решение

Я бы сделал сущность с именем "Комментарий" и добавил бы сопоставление отношений для этой сущности комментария с пользователем. Сущность комментария также будет содержать перечисляемое значение в одном столбце с указанием, является ли оно для изображения или для видео. Что-то вроде -

enum MimeType {
    PICTURE, VIDEO;
}

class Comment {
    @ManyToONe
    private User user;
    @Enumerated
    private MimeType mimeType;
}

Почему мне нравится этот подход? Потому что его чище, и в результате сущности будут меньше, и мне не нужно писать разные запросы для поиска разных типов комментариев MIME-типа. И так как комментарии находятся в таблице сравнения, я могу загружать их лениво.

Источник

Я бы использовал ваш подход № 2, потому что тогда гораздо проще делать такие вещи, как "Поиск по всем комментариям"

Источник

Вы можете иметь только одну таблицу комментариев, где в одном поле будет указан тип комментария. Это в основном вариант 2 без отображения, достаточно одного поля, чтобы узнать, какой это тип комментария. Что касается идентификатора видео или изображения, вы можете рассматривать их как общие объекты, а потребитель может решить, что с ними делать, основываясь на типе, комментарии или типе пантомимы объекта. Это должно позволить вам добавлять больше типов комментариев в будущем.

Comment
 id
 user_id
 comment_text
 comment_type
 linked_object_id

CommentObect
  id
  type
  object
Источник

Вам нужно только три объекта (или два, если вы не включите объект пользователя).

Ваш подход 2 подразумевает, что конкретный комментарий может содержать более одного изображения или видео. Это то, что вы хотите?

Пользователь {one-to-many} комментарий {много-к-одному} медиа (тип медиа)

Источник
Другие вопросы по тегам