Схема БД для Фейсбука типа Стена + "Общие ссылки"

Question

Я делаю схему БД для Facebook, как структура стены. Мне нужно сохранять посты на стене, делиться ссылкой, делиться видео в моей базе данных. До сих пор я могу сделать эту схему:

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL 
    )
GO   

Далее мне нужно добавить схему для добавления функции «поделиться ссылкой» и «поделиться видео».

GO
CREATE TABLE [Wall]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [WallText] [nvarchar](MAX)
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [DateCreated] [datetime] NULL,

      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO

Теперь с этой схемой:

1-й случай: при вставке сообщения на стене столбцы [SharedLink], [SharedLinkTitle], [SharedLinkDesc], [SharedLinkImageSrc] будут вставлены как нулевые, а остальные столбцы будут иметь значения.

2-й случай: когда вставлена ​​ссылка общего доступа, столбец «[WallText]» будет вставлен как ноль, а остальные столбцы будут иметь значения.

В моем случае 70% времени будет сделано на стене, и 30% «ссылок» будут переданы, что означает 70% случаев [SharedLink], [SharedLinkTitle], [SharedLinkDesc], [SharedLinkImageSrc] будет вставлено как ноль. Теперь я обеспокоен тем, что можно оставить вставленные пустые столбцы или я должен использовать отдельную таблицу для "общей ссылки" и разделить таблицу следующим образом:

GO
CREATE TABLE [LinkShared]
    (
      [ID] [int] NOT NULL IDENTITY(1, 1) ,
      [PostedByUserID] [int] NULL ,
      [PostedOnUserID] [int] NULL ,
      [SharedLink] [nvarchar](1024)  NULL ,
      [SharedLinkTitle] [nvarchar](512)  NULL ,
      [SharedLinkDesc] [nvarchar](512)  NULL ,
      [SharedLinkImageSrc] [nvarchar](512)  NULL 
    )
GO 

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

Answer 1

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

Answer 2

Использование двух отдельных таблиц выглядит здесь как разумный подход - похоже, у этих двух таблиц очень мало общего.Объединение несвязанных объектов в одну таблицу и использование NULL для неприменимых столбцов, как правило, является плохим проектом.

В более общем случае, если у вас есть два типа объектов, которые отличаются в некоторых отношениях, но также совместно используют некоторыеобщие черты, а другая альтернатива, на которую вы могли бы обратить внимание, - это метод, который иногда называют «наследованием таблиц»:

• Методы наследования баз данных?
• Реализация наследования таблиц в SQL Server

При первом подходе вы используете одну таблицу, которая содержит все данные.Во втором подходе вы используете две таблицы, которые полностью разделены.Подход наследования использует три таблицы - одну для общих столбцов и дополнительную таблицу для каждого специализированного типа.Затем вы используете отношение внешнего ключа, чтобы связать запись в общей таблице с записью в одной из конкретных таблиц, чтобы вы могли присоединиться, чтобы получить полный объект.Существует несколько различных способов создания этих отношений, которые описаны в статье, на которую я ссылался выше.

Но не злоупотребляйте наследованием таблиц.Например, две таблицы могут иметь несколько столбцов (ID, inserttion_date), но в остальном это две концептуально разные вещи.Тогда, вероятно, было бы неуместно использовать эту технику для выделения общих столбцов.Я не знаю достаточно о вашей конкретной ситуации, чтобы сказать, имеет ли смысл использовать эту технику на постах «Стена» и «Поделиться ссылкой», но вы можете рассмотреть ее.

Чтобы датьпример того, когда может быть полезно использовать эту технику вместо двух отдельных таблиц: если вы хотите запросить десять самых последних сообщений пользователя (независимо от того, являются ли они сообщениями на стене или общими ссылками), то полезно иметь однутаблица, где вы можете получить идентификаторы для этих сообщений с помощью одного простого запроса.Если у вас есть две совершенно разные таблицы, между которыми нет связи, запрос более сложный - сначала вы должны получить первые 10 из каждой таблицы, объединить результаты, а затем получить первые 10 из объединения.