Лучший результативный подход к механизму истории?

Question

Мы собираемся создать механизм истории для наших изменений в БД ( DART на рис.) С помощью триггеров.

у нас 600 столов.

Каждая запись, которая будет изменена - триггер вставит удаленную в XXX .

---

относительно XXX :

опция 1 : клонировать каждую таблицу в БД «Dart», и теперь у каждой таблицы будет «сестринская таблица»

например. : Table1 будет иметь Table1_History

проблем:

• у нас будет 1200 столов
• программист может ошибаться, работая с неверными таблицами ...

---

опция 2 : создайте новую БД (DART_2005 на рис.), И таблицы истории будут там

---

опция 3 : использовать связанный сервер, который хранит базу данных, в которой будут храниться таблицы истории.

---

вопрос:

1) , какой вариант дает лучшую производительность (я думаю, 3 нет - но это 1 или 2 или то же самое?)

2) Действует ли вариант 2 как "связанный сервер" (в запросах нам нужно будет выбрать обе базы данных ...)

3) Каков наилучший практический подход?

Answer 1

Все три подхода жизнеспособны и имеют одинаковую производительность в зависимости от скорости вашей сети, но каждый из них вызовет много головной боли в системе с множеством одновременных пользователей.

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

Если существующая схема таблицы не может быть изменена

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

• Запустить триггер при обновлении таблицы
• Триггер отправит сообщение, содержащее информацию из вставленных / удаленных таблиц, в Компонент SQL Server Service Broker Очередь
• Хранимая процедура активации может извлечь информацию из очереди и записать ее в соответствующую таблицу истории
• При сбое новое сообщение отправляется в «очередь ошибок», где механизм повторных попыток может повторно отправлять исходную очередь (убедитесь, что в сообщение включен счетчик повторов)

Таким образом, ваши обновления истории будут неблокирующими и не могут потеряться.

Примечание: при работе с брокером SQL Server Service убедитесь, что вы полностью понимаете концепцию «Ядовитое сообщение».

Если существующая схема таблицы может быть изменена

Когда это опция, я рекомендую работать с системой «Управление версиями записей», в которой каждое обновление будет создавать новую запись, и ваше приложение будет правильно запрашивать самую последнюю версию данных. Чтобы обеспечить надлежащую производительность, таблицу можно разбить на части, чтобы сохранить самые последние версии данных в разделе и более старые версии в разделе архива. (У меня обычно есть поле end_date или expiration_date, которое установлено на 9999/12/31 для текущей действующей записи.)

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

Answer 2

1 и 2 будут иметь одинаковую производительность;вариант 3 может быть быстрее, если вы в настоящее время ограничены каким-либо ресурсом на сервере базы данных (например, дисковым вводом-выводом), и вам доступна очень быстрая сеть.

Вариант 1 будетпривести к увеличению времени резервного копирования базы данных DART - это может быть проблемой.

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

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