Блог

Главная - Вопросы по программированию - Проект / Проектирование базы данных системы живого контента

Проект / Проектирование базы данных системы живого контента

#sql #database #database-design

#sql #База данных #проектирование базы данных

Вопрос:

Я работал над проектом, который требует черновых / живых версий контента, и подумал о дизайне, таком как показано ниже:

 Article
    ID
    Creator
    CreationDate
    DraftContent(fk to ArticleContent)
    PublicContent(fk to ArticleContent)
    IsPendingApproval

ArticleContent
    Title
    Body

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

Есть какие-нибудь предложения?

Редактировать: как черновик, так и живые версии существуют одновременно, хотя живая версия — единственная, которая видна публике. Может быть только один драфт и один живой стол

Одна из причин такого дизайна заключается в том, чтобы заставить пользователей получать одобрение своих статей до того, как они выйдут в эфир.

Обновить:

Мы решили использовать решение Кирена с небольшой модификацией. Вместо использования столбца для таких элементов, как IsPublished isLive, мы решили использовать один столбец состояния. В остальном дизайн остался прежним.

Ответ №1:

Проекты статей, которые становятся живыми, а затем «публикуются»

Обычным делом было бы иметь флаг статуса / типа в таблице статей — IsLive .

Использование отдельных таблиц не является необходимым и избыточным; изменение внешних ключей также не имеет особого смысла. Думайте о статье как о действительном объекте, будь то черновик или живой. Единственное отличие в том, что в большинстве случаев вы хотите отображать только живые статьи. В некоторых случаях в будущем вы можете захотеть отобразить оба.

Статьи, которые могут быть отредактированы и иметь новую черновую версию после первоначального запуска

С точки зрения одной статьи, имеющей как текущую, так и черновую версию, наиболее распространенным шаблоном было бы иметь главную Article сущность / объект, а затем сказать ArticleVersion , исходя из этого. У ArticleVersion него было бы IsLive свойство или, что еще лучше, у Article самого было бы свойство, CurrentLiveVersionId . Таким образом, могут существовать текущие и черновики версий, но обычно вы только присоединяетесь Article к ArticleVersion ним, CurrentLiveVersionId чтобы получить текущую текущую версию.

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

Дайте мне знать, если я смогу разъяснить этот метод.

Комментарии:

1. 1, «единая таблица статей с отдельным содержанием» — это действительно способ попасть сюда.

2. Потенциально очень просто — каждый ArticleVersion будет иметь ApprovedBy / ApprovedDate, если он не может быть установлен на текущую версию, если это значение равно нулю (в бизнес-логике)?

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

4. Идентификаторы очень важны в RDBB. Как такового «номера версии» нет, но я даже думаю, что он должен существовать. Вместо CurrentLiveVersionId, если вы полагаетесь на даты, вы могли бы иметь a PublishDate для каждой версии, а затем при отображении статьи извлекать статью с первым PublishDate более старым, чем сейчас, утвержденным (утвержденный важный бит).

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

Ответ №2:

Ваш дизайн мне кажется подходящим. Когда новая версия будет запущена, я бы:

  1. UPDATE PublicContent ключ к указанию на (бывший) проект статьи.
  2. DELETE ранее опубликованная статья, на которую больше нет ссылок.
  3. NULL ключ DraftContent или, если ваша модель требует всегда иметь черновую версию, INSERT новый, пустой черновик ArticleContent и укажите на DraftContent него ключ.
Метки: