Как создать базу данных с помощью Revision History? - PullRequest
20 голосов
/ 19 сентября 2011

Я являюсь частью команды, создающей новую систему управления контентом для нашего публичного сайта.Я пытаюсь найти самый простой и лучший способ встроить механизм контроля версий.Объектная модель довольно проста.У нас есть абстрактный класс «BaseArticle», который включает свойства для независимых от версии / метаданных, таких как «Заголовок» и «CreatedBy».Ряд классов наследуется от этого, например, «DocumentArticle», который имеет свойство «URL», который будет путь к файлу.«WebArticle» также наследует от «BaseArticle» и включает в себя свойство «ДалееInfo» и коллекцию объектов «Tabs», которые включают в себя «Body», который будет содержать HTML-код для отображения (объекты Tab не являются производными от чего-либо).«NewsArticle» и «JobArticle» наследуют от «WebArticle».У нас есть другие производные классы, но они предоставляют достаточный пример.

Мы придумали два подхода к сохранению для Revision Control.Я называю это «подход 1» и «подход 2».Я использовал SQL Server для составления базовой диаграммы каждого из них: Database Diagram of Approach 1 Database Diagram of Approach 2

При подходе 1 план будет предусматривать сохранение свежих версий статей через обновление базы данных.Триггер будет установлен для обновлений и вставит старые данные в таблицу xxx_Versions.Я думаю, что триггер должен быть настроен на каждой таблице.Преимущество этого подхода состоит в том, что в основных таблицах хранится единственная «головная» версия каждой статьи, а старые версии отключаются.Это облегчает копирование головных версий статей из базы данных разработки / подготовки в живую.

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

Обратите внимание, что при обоих подходах планируется вызвать хранимую процедуру Upsert для таблицы, сопоставленной с соответствующим объектом (мынеобходимо помнить, чтобы обрабатывать случай добавления новой статьи).Эта хранимая процедура upsert вызовет так, что для класса, из которого она получена, например, upsert_NewsArticle вызовет upsert_WebArticle и т. Д.

Мы используем SQL Server 2005, хотя я думаю, что этот вопрос не зависит от вида базы данных.Я провел несколько обширных поисков в интернете и нашел ссылки на оба подхода.Но я не нашел ничего, что сравнило бы эти два и показало бы одно или другое, чтобы быть лучше.Я думаю, что со всеми книгами по базам данных в мире, этот выбор подходов должен был возникнуть раньше.

Мой вопрос: какой из этих Подходов является лучшим и почему?

Ответы [ 2 ]

1 голос
/ 24 мая 2019

В целом, наибольшее преимущество для таблиц истории / аудита - это производительность:

  • Запрашивать любые активные / активные данные можно из гораздо меньшей основной таблицы

  • Любые запросы «только в режиме реального времени» не должны содержать флаг active / latest (или, не дай бог, сделать коррелированный подзапрос на отметке времени, чтобы выяснить последнюю строку), упрощая код как для разработчиков, так и для оптимизатора движка БД.

Однако для небольших CMS с 100 или 1000 строками (а не миллионами) выигрыш в производительности будет довольно небольшим.

Таким образом, для небольших CMS подход 3 был бы лучше, поскольку он проще: меньше кода, меньше движущихся частей.

Подход 3 почти такой же, как и подход 2, за исключением того, что каждая таблица, для которой требуется история / управление версиями, имеет явный столбец, содержащий true / false «активный» (a.k.a. live - a.k.a. latest) - столбец флага.

Ваши upserts отвечают за правильное управление этим столбцом при вставке новой активной версии (или удаления текущей активной версии) строки.

Все ваши «живые» запросы на выборку за пределами UPSERT будут затем тривиально изменить, добавив «AND mytable.live = 1» к любому запросу.

Кроме того, мы надеемся, что это очевидно, но ЛЮБОЙ индекс в любой таблице должен начинаться с «активного» столбца, если не гарантировано иное.

Этот подход объединяет простоту подхода 2 (без дополнительных таблиц / триггеров) с производительностью подхода 1 (нет необходимости делать коррелированный подзапрос для любой таблицы, чтобы найти последнюю / текущую строку - ваши upserts управляют этим с помощью активного флага)

0 голосов
/ 14 июня 2018

Ни то, ни другое.

CMS сложна, и может возникнуть реальная боль, когда приходится иметь дело с заблокированными файлами базы данных, когда кто-то отключает интернет. Поскольку вы используете MSSQL, просто можете загрузить и использовать подпадающие под GPL программы Joomla !, mediaWiki или Magnolia и избавить свою компанию от головной боли, когда вы решите уйти.

Тем не менее, что-то похожее - это то, как я обычно вижу реализованные системы CMS.

...