Комментарии по многим таблицам дизайна базы данных - PullRequest
Новая
       3

Комментарии по многим таблицам дизайна базы данных

2 голосов
/ 20 апреля 2011

У меня есть таблицы: 

Articles{...}
Recipes{...}
Notifications{...}
Photos{...}

И мне нужно реализовать функцию комментариев пользователей (например, facebook). Должен ли я создавать таблицы: ArticleComments, RecipesComments и т. Д. С отношением 1: n? Или создать одну Comments таблицу для всех (но я не знаю, как ее спроектировать)?

Ответы [ 5 ]

4 голосов
/ 20 апреля 2011

Вы можете создать другую таблицу CommentableEntity (хотя назовите ее как-нибудь лучше). Каждая из строк в ваших таблицах (Articles, Recipes и т. Д.) Будет иметь ссылку на уникальную строку в этой таблице. Таблица сущностей может иметь поле type для указания типа сущности (для облегчения обратного объединения).

Затем вы можете иметь Comment таблицу, которая ссылается на CommentableEntity в общем виде.

Так, например, вы получите следующие таблицы: 

Articles
-----------------
Article_id
CommentableEntity_id (fk, unique)
Content
....

Recipes
-----------------
Recipe_id
CommentableEntity_id (fk, unique)
Content
....

CommentableEntity
-----------------
CommentableEntity_id (pk)
EntityType (e.g. 'Recipe', 'Article')

Comment
-------
Comment_id (pk)
CommentableEntity_id (fk)
User_id (fk)
DateAdded
Comment 
...etc...

Вы можете добавлять запись CommentableEntity каждый раз, когда добавляете статью / рецепт и т. Д. Все, что должен знать ваш код обработки комментариев - это CommentableEntity_id - ему все равно, какой это тип вещи.

2 голосов
/ 20 апреля 2011

Это зависит от того, как ваше приложение будет использовать комментарии.

Я предполагаю, что вы часто захотите просмотреть все комментарии, созданные пользователем, независимо от сущности, которую они комментируют. То есть, я предполагаю, что вам часто потребуется запрос, который возвращает строки, указывающие, что пользователь JohnDoe прокомментировал статью 1, затем фотографию 12, а затем рецепт 171. Если это так, то было бы гораздо разумнее иметь один * 1003. * таблица со структурой, аналогичной той, которую Стив Мейн предложил с таблицей CommentableEntity.

С другой стороны, если вы хотите получить доступ только к комментариям для определенного элемента (т. Е. Ко всем комментариям к статье 1), отдельные таблицы ArticleComments и PhotoComments могут быть более подходящими. Это облегчает размещение внешних ключей между таблицей сущностей и таблицей комментариев и потенциально немного более эффективно, так как это разделение бедняков. Конечно, как только вы начнете комбинировать данные из нескольких таблиц комментариев, эта эффективность исчезнет, ​​поэтому вам нужно быть достаточно уверенным в сценариях использования.

0 голосов
/ 06 мая 2014 
SELECT TOP 1000 [Comments_Id]
      ,[Comments_Text]
      ,[Comments_IsApproved]
      ,[Comments_IsVisible]
      ,[Comments_DateStamp]
      ,[Type_Id]
      ,[Entity_Id] -- From Entity Table, listing Articles, Recipes etc. 
      ,[EntityItem_Id] -- One of the PK from table of Articles, Recipes etc.
      ,[User_Id]
  FROM [tbl_Comments]
0 голосов
/ 20 апреля 2011

Самый простой способ - создать «полиморфную» таблицу комментариев, в которой будут столбцы как для идентификатора, так и для типа объекта, на который она ссылается.

Вы можете сделать следующее: 

SELECT * FROM Comments where type = "Articles" and type_id = 1;
SELECT * FROM Comments where type IN ("Recipes", "Photos")

Добавление уникального составного индекса (type, id) также улучшит производительность поиска.

0 голосов
/ 20 апреля 2011

Чтобы иметь представление о том, как создать единую таблицу Comments для всех объектов, вы можете взглянуть на django comment model (http://docs.djangoproject.com/en/dev/ref/contrib/comments/models/)

...