Плюсы и минусы триггеров против хранимых процедур денормализации

Question

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

1. принудительное обновление через хранимые процедуры, которые обновляют как нормализованные транзакционные данные, так и денормализованные данные отчетности / анализа;

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

3. Отложите обработку до ночной пакетной обработки, возможно, сделав ETL в витрине / хранилище данных.

Предположим, что для целей этого вопроса вариант № 3 нежизнеспособен, поскольку домен требует, чтобы денормализованные данные всегда были согласованы с нормализованными данными. Иерархические агрегаты, с которыми я имею дело довольно часто, являются одним из примеров этого.

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

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

(P.S. Пожалуйста, не отвечайте, например, «триггеры слишком сложны» или «все обновления всегда должны проходить через сохраненный процесс» - сделайте это соответствующим контексту вопроса.)

Answer 1

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

Мы используем хранимые процедуры и по крайней мере около 4 путей (Добавить, Обновить, Деактивировать, Копировать)

Прощеработать с данными, которые мы только что вставили / обновили в триггере, независимо от того, какое действие мы делаем или на какое количество строк мы влияем.

Хранимый процесс работает только для одного пути обновления, я чувствую: если вы не хотитеповторить код ...

Теперь TRY / CATCH в триггерах означает правильную, предсказуемую обработку ошибок: триггеры в SQL Server 2000 и более ранних версиях вызывали прерывание пакета при ошибке / откат, что не идеально (по меньшей мере!),Так что триггеры теперь более надежны.

Answer 2

Триггеры - это автоматические побочные эффекты, которые почти наверняка укусят вас, когда вы захотите что-то сделать, а не из-за побочных эффектов триггеров. В основном такие вещи, как участие вашей системы в некоторая транзакция XA с другими внешними системами. Триггеры делают это НЕВОЗМОЖНЫМ. Также это логика побочных эффектов, которая может быть активирована ТОЛЬКО путем повторного запуска триггера. Если вы хотите воссоздать данные в хранилище, вы не можете просто запустить какую-то процедуру и воссоздать ее, вам нужно выполнить все действия, которые будут запускать триггеры, это кошмар. ВСТАВКИ, ОБНОВЛЕНИЯ и УДАЛЕНИЯ должны быть идемпотентными и ортогональными. Триггеры неоправданно усложняют рабочие процессы, даже если вы думаете, что они их упрощают, но это не так.

Answer 3

Это зависит от ваших бизнес-требований и от того, как используется ваша база данных.Например, предположим, что есть много приложений и много импортов, которые влияют на таблицу (у нас есть сотни вещей, которые могут повлиять на наши таблицы).Предположим также, что иногда возникает необходимость в написании запросов, которые запускаются из SSMS (да, даже в prod) для таких вещей, как обновление всех цен на 10%.Если вы делаете такие вещи, то сохраненный процесс нецелесообразен, у вас никогда не будет всех возможных способов повлиять на охватываемую базу данных.

Если это изменение данных необходимо для обеспечения целостности данных или многие приложения или процессы (импорт, задания SQL Server и т. Д.) Могут влиять на данные, то они принадлежат триггеру.

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