Схема SQL, позволяющая пользователям добавлять комментарии к различным таблицам

Question

Итак, я создаю веб-сайт, и у меня будут стандартные таблицы CMS, такие как Article, Blog, Poll и т. Д. Я хочу, чтобы пользователи могли оставлять комментарии к любому из этих элементов. Поэтому мой вопрос заключается в том, нужно ли создавать отдельные таблицы комментариев для каждой (например, ArticleComment, BlogComment, PollComment), или я могу просто создать общую таблицу комментариев, которую можно использовать с любой таблицей? Что сработало для людей?

Способ 1: множество таблиц комментариев

• Article {ArticleID [PK], Title, FriendlyUrl}
• ArticleComment {ArticleCommendID [PK], ArticleID [FK], Комментарий}
• Blog {BlogID, Title, PubDate, Category}
• BlogComment {BlogCommendID [PK], BlogID [FK], Комментарий}
• Опрос {PollID, Title, IsClosed}
• PollComment {PollCommentID [PK], PollID [FK], Комментарий}

Метод 2: Таблица с одиночными комментариями

• Article {ArticleID [PK], Title, FriendlyUrl}
• Blog {BlogID, Title, PubDate, Category}
• Опрос {PollID, Title, IsClosed}
• Комментарий {CommentID [PK], ReferenceID [FK], Комментарий}

Answer 1

Существует два основных способа отображения ОО-наследования в реляционных базах данных:

1. Возьмите все атрибуты из родительского класса и всех дочерних классов и поместите их в таблицу вместе с 'каким классом это?' поле. Каждый объект сериализуется как одна строка в одной таблице.

2. Создайте одну таблицу для родительского класса и одну таблицу для каждого дочернего класса. Таблица для родительской таблицы классов содержит «какой класс это?» поле. Таблица дочерних классов содержит внешний ключ, указывающий на таблицу родительских классов. Каждый объект сериализуется как одна строка в таблице родительского класса и одна строка в таблице дочернего класса.

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

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

Я предлагаю взглянуть на второй метод для ваших таблиц статей / опросов / блогов - для меня они звучат как дочерние таблицы Content или что-то в этом роде. После этого у вас будет очень простое и удобное место для добавления комментариев: к Content.

Answer 2

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

Answer 3

Почему вы хотите сохранить все ваши комментарии в одной таблице? Будете ли вы рассматривать все комментарии как группу? Если вы не планируете работать со всеми комментариями по всем пунктам как с одной группой, то нет никакой причины объединять их все вместе. Тот факт, что две сущности в базе данных имеют одинаковые атрибуты, не означает, что они должны быть помещены в одну физическую таблицу.

Answer 4

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

  Data Table(s)      Many-to-many Assoc             Comment Table
  CommentableId  ->  CommentableId/CommentId   ->   Comment_Id

Не мой дизайн, но мне нравится гибкость. Это позволяет нам использовать один комментарий во многих разные места. Поскольку это не тривиально реализовать в пользовательском интерфейсе, пользователи не видят эту функцию (просто текстовое поле для ввода комментария), но она используется, когда мы выполняем пакетный импорт и традиционную обработку данных в базе данных. 1004 *

Answer 5

Я бы предложил только одну таблицу комментариев, добавив поле ItemID, сообщающее, к какому типу элементов относится комментарий:

Article {ArticleID [PK], Title, FriendlyUrl}
Blog {BlogID, Title, PubDate, Category}
Poll {PollID, Title, IsClosed}
Comment {CommentID [PK], ReferenceID [FK], ItemID, Comment}
Item {ItemID, Type}

Последняя таблица будет содержать записи, такие как (1, «статья»), (2, «блог») и т. Д.

Таким образом, вы сможете определить тип контента для каждого комментария.