Я пытаюсь создать простую структуру для приложения в стиле социальной сети. Но я немного путаюсь в том, как спроектировать отношения между posts, comments и medias. Проще говоря, media может быть image или video (с перечислением). Он содержит size и URL информацию о стандартном изображении, миниатюре и видео (в соответствии с перечислением mediaType). A post может иметь несколько media прикрепленных к нему. A comment может иметь несколько media прикрепленных к нему. Но когда media используется в одном месте, его нельзя использовать в другом. Ни один другой post не может иметь его. Ни один другой comment не может иметь его. Кроме того, когда я реализую users, они могут ссылаться на тип изображения media в качестве своего профиля Pi c. Когда появится функция messaging, некоторые media могут быть присоединены к message et c. Итак, я хочу, чтобы все было немного гибче.
Я не хотел добавлять определенные c столбцы примерно thumbnailWidth, thumbnailSize, thumbnailURL et c в несколько таблиц, потому что это было бы слишком много повторений. Поэтому я решил использовать централизованную таблицу media для хранения всей основной информации о загруженном изображении или видео. Я решил поместить миниатюру и стандартную информацию об изображении в один ряд, иначе это было бы слишком сложно для обработки. Позже я могу разделить images и videos на отдельные таблицы.
Примечание: у меня нет структуры комментариев, чтобы отвечать друг другу. Это более поздняя проблема:)
Вот текущий дизайн без связи между media и другими таблицами.
Media
----------
id
thumbnail_width
thumbnail_height
thumbnail_URL
standard_width
standard_height
standard_URL
media_type ("video" or "image")
source_URL (only used if media_type is "video")
(maybe other columns to be used with "video" type)
user_id (who uploaded the media)
Post
----------
id
title
body
user_id (who sent the post.)
Comment
----------
id
body
post_id (which post has this comment)
user_id
Опция 1
Итак один из вариантов - поместить поля commentId и postId (как обнуляемые) в таблицу media. Если к сообщению прикреплен носитель, поместите туда postId. Если он прикреплен к комментарию, сделайте то же самое для commentId. Если один из них имеет значение, другие должны быть null. Но это может привести к слишком большому количеству ссылочных столбцов в таблице media, поскольку media может использоваться во многих местах по мере роста проекта.
Option2
Другим вариантом является создание таблиц для каждого отношения, например:
PostMedia
----------
id
post_id
media_id (unique. one-to-one relationship with Media table)
CommentMedia
----------
id
comment_id
media_id (unique. one-to-one relationship with Media table)
Но теперь становится сложнее проверить, используется ли носитель в post, перед сохранением comment. Или наоборот. Нам нужно каждый раз проверять всю таблицу PostMedia.
Другая ситуация может возникнуть, когда пользователь устанавливает media с типом image в качестве своего изображения профиля, нам нужно проверить, было ли оно используется в сообщении или комментарии. Я не уверен насчет этого ограничения, но оно может пригодиться в некоторых ситуациях.
Я мог бы установить перечисление ownerType в таблице media. Это может быть post, comment, profilePic et c. И таблица PostMedia может ссылаться на носитель, только если ownerType равен post.
Опция 3
Идея централизованной таблицы Media - это круто, но она приходит с большой сложностью я думаю. С объектно-ориентированным дизайном я мог бы просто создать абстрактный класс media, поместить все необходимые столбцы и методы в этот класс и расширить его как PostMedia, CommentMedia et c. И с этим было бы гораздо проще справиться, но в итоге получилось бы много одинаковых столбцов и похожих таблиц по всей БД. Я не знаю, хороший ли это дизайн.
Что было бы лучшим вариантом здесь? Я мог бы думать, что вещи слишком сложные, могут быть более простые решения. Я открыт для любых советов:)
Спасибо!