Введение

Часто возникает дебаты о использовании триггеров в базах данных SQL Server. Некоторые считают, что триггеры никогда не должны использоваться, в то время как другие считают, что они имеют свое место. В этой статье мы объективно проанализируем триггеры SQL Server (как DDL, так и DML) и сравним их с ограничениями, чтобы определить преимущества и недостатки каждого подхода.

Триггеры против ограничений

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

На основе наших экспериментов мы обнаружили, что ограничения работают быстрее, чем триггеры. В нашем примере ограничения были в среднем на 7% быстрее. Поэтому рекомендуется использовать первичные ключи, уникальные ограничения, значения по умолчанию, внешние ключи и проверочные ограничения при возможности, чтобы обеспечить целостность данных и улучшить производительность.

Отслеживание исторических записей с использованием триггеров

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

Наши эксперименты показали, что в некоторых случаях триггеры работают на 35% быстрее, чем выходной параметр OUTPUT. Поэтому, если вам нужно создавать исторические записи изменений таблицы, замена триггеров выходным параметром OUTPUT может не улучшить производительность. Триггеры обеспечивают больший контроль над кодом и могут быть хорошим выбором, когда вам нужно добавить функциональность для операций вставки, удаления и обновления.

SQL Profiler против триггеров

SQL Profiler – это инструмент, который позволяет отслеживать события SQL Server, такие как вставки, обновления и удаления. Некоторые могут задаться вопросом, можно ли использовать SQL Profiler в качестве альтернативы триггерам для отслеживания событий. Однако SQL Profiler потребляет значительное количество ресурсов и рекомендуется запускать на отдельном сервере. Не рекомендуется заменять триггеры на SQL Profiler.

DDL триггеры против расширенных событий

DDL триггеры используются для выполнения действий для событий, таких как создание новой базы данных или изменение таблицы. Однако расширенные события становятся рекомендуемой альтернативой триггерам. Расширенные события проще и потребляют меньше ресурсов по сравнению с SQL Profiler. Они могут использоваться для обнаружения событий, таких как создание базы данных.

Заключение

В заключение, ограничения следует использовать при возможности вместо триггеров, потому что они работают быстрее, легче поддерживаются и требуют меньше кода. Выходной параметр OUTPUT не является лучшим выбором по причинам производительности. SQL Profiler не следует использовать в качестве замены триггеров из-за его потребления ресурсов и устаревания. Расширенные события могут быть хорошей альтернативой DDL триггерам в определенных сценариях.

Ссылки:

• Каталоговые представления расширенных событий (Transact-SQL)
• Использование расширенных событий для просмотра неудачных попыток входа в систему SQL Server
• CREATE TRIGGER (Transact-SQL)
• SQL Server Profiler