#database-design
#database-design
Вопрос:
Я разрабатываю базу данных для приложения, в котором пользователь может комментировать изображения и видео.
Должен ли я хранить отдельные таблицы для комментариев типа (Picture_comments amp; videos_comments)
ИЛИ
мне следует сохранить одну таблицу для комментариев и других таблиц сопоставления, таких как (picture_comment_mapping amp; 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
Какой подход лучше и почему?
Ответ №1:
Я бы использовал ваш подход номер 2, потому что тогда гораздо проще выполнять такие вещи, как «Поиск по всем комментариям»
Ответ №2:
Я бы создал объект с именем «Комментарий» и добавил сопоставление отношений к этому объекту комментария с пользователем. Объект комментария также будет содержать перечисляемое значение в одном столбце, указывающее, относится ли оно к изображению или к видео. Что-то вроде —
enum MimeType {
PICTURE, VIDEO;
}
class Comment {
@ManyToONe
private User user;
@Enumerated
private MimeType mimeType;
}
Почему мне нравится этот подход? Потому что она более чистая, и результирующих объектов будет меньше, и мне не придется писать разные запросы для поиска разных типов комментариев типа mime. И поскольку комментарии находятся в таблице различий, я могу загружать их лениво.
Комментарии:
1. Я использовал этот подход, потому что объекты, которые могут быть прокомментированы, исправлены, поэтому enum легко решит проблему. Кроме того, перечисления будут выполняться быстрее, и количество таблиц также уменьшится (таким образом, уменьшая количество объединений)
Ответ №3:
У вас может быть только одна таблица комментариев, где одно поле будет определять тип комментария. По сути, это вариант 2 без сопоставления, достаточно одного поля, чтобы узнать, к какому типу относится комментарий. Что касается идентификатора видео или картинки, вы можете рассматривать их как универсальные объекты, и потребитель может решить, что с ними делать, на основе типа, комментария или объекта mime-типа. Это должно позволить вам добавлять больше типов комментариев в будущем.
Comment
id
user_id
comment_text
comment_type
linked_object_id
CommentObect
id
type
object
Комментарии:
1. Если я использую ENUM, то дизайн не будет реляционным.
Ответ №4:
Вам нужно всего около трех объектов (или двух, если вы не включаете объект User).
Ваш подход 2 подразумевает, что конкретный комментарий может относиться к нескольким изображениям или видео. Это то, чего вы хотите?
Пользовательский комментарий {один ко многим} {многие к одному} носитель (тип носителя)
Комментарии:
1. Нет, я не хочу этого таким образом. Мне нужен один комментарий для каждого объекта ‘
2. Я бы сказал, что единственное, что подразумевает подход 2, это то, что комментарий к типу A имеет ту же форму, что и комментарий к B, что они и делают.
3. извините, не знаю, почему я так подумал. Исправили это. @RAHUL: Я думаю, вы имели в виду «один объект на комментарий и ноль, один или более комментариев на объект»