Руководство по триггерам

В мире стартапов с открытыми исходными кодами и разработкой полного стека (типа Django, Rails, Javascript, PHP, MySQL, Postgres…) очень популярны ORM, а средства типа триггеров SQL не так востребованы.

Но все же триггеры SQL сохраняют свое значение. Когда я работал над нестандартной ERP-системой, триггеры оказались неоценимым инструментом. При построении сильно ориентированного на данные ПО, особенно с данными в финансовой сфере, где точность является главным требованием, вы с большей вероятностью увидите, что данные обрабатываются непосредственно на более низком уровне.

В этой статье я поделюсь информацией о том, как эффективно использовать триггеры SQL.

Содержание

1. Что такое триггер?
2. Как создать триггер SQL — синтаксис PostgreSQL
3. Пример триггера в PostgreSQL #1: создание таймера
4. Пример триггера в PostgreSQL #2: создание таблицы аудита
5. Дополнительные соображения о триггерах

Что такое триггер?

Триггеры SQL, также называемые триггерами баз данных, позволяют вам сказать движку SQL (например PostgreSQL) выполнить часть кода при наступлении некоторого события, или даже перед наступлением события.

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

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

Преимущества использования триггеров SQL

Поддержание целостности данных

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

Разделение бизнес-логики

Размещение критичной бизнес-логики в коде приложения также представляет проблему, когда бизнес-логика обновляется. Если вашим бизнес-требованием являлось умножение входящих номеров на 10, а теперь вы захотели умножать это число на 20, изменение логики в SQL гарантировало бы, что каждые данные, начиная точно с момента развертывания, будут обрабатываться новой логикой.

Сервер SQL действует как единственная точка истины. Если логика внедрена на множестве серверов приложений, вы не сможете ожидать определенного изменения в поведении, выполненного чисто.

Атомарные транзакции

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

Как создать триггер SQL: синтаксис PostgreSQL

Вот составляющие создания триггера для вашей базы данных:

1. Тип события триггера
2. До или после события
3. Воздействие триггера

Типы событий триггера

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

Триггер базы данных допускает также перечисление более одного из этих событий.

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

Триггер BEFORE (до) или AFTER (после)

Триггер может выполняться либо до, либо после события.

Если вы хотите заблокировать событие типа INSERT, вы захотите выполнять действие до (BEFORE). Если вы хотите быть уверенным, что событие действительно произойдет, идеальный вариант — после (AFTER).

Воздействие триггера

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

Если вы укажете в триггере FOR EACH ROW, тогда триггер выполнится 5 раз. Если вы укажете FOR EACH STATEMENT, тогда он выполнится только раз.

И, конечно, мы не можем забыть о фактическом коде, который выполняется при срабатывании триггера. В PostgreSQL он помещается в функцию и отделен от триггера. Разделение триггера и кода, который он выполняет, создает более чистый код и позволяет нескольким триггерам выполнять один и тот же код.

Пример триггера #1: создание таймера

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

Настройка схемы базы данных

Структура схемы предполагает каждый вход и выход отдельными событиями. Каждое событие — это строка в таблице time_punch. Как альтернативу вы можете также сделать каждую «рабочую смену» сотрудника событием и хранить время как входа, так и выхода в одной строке.

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

Для нашего примера я уже разработал схему таблиц. Нижеприведенный код создает таблицы employee и time_punch и вставляет некоторые данные по времени прохода для нового сотрудника Bear.

create table employee ( id serial primary key, username varchar );

create table time_punch (

  id serial primary key,

  employee_id int not null references employee(id),

  is_out_punch boolean not null default false,

  punch_time timestamp not null default now()

);

insert into employee (username) values ('Bear');

insert into time_punch (employee_id, is_out_punch, punch_time)

values

(1, false, '2020-01-01 10:00:00'),

(1, true, '2020-01-01 11:30:00'); 

Bear зашел в 10:00 и вышел в 11:30 (длинный рабочий день). Давайте напишем запрос SQL для вычисления рабочего времени Bear.

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

Использование SQL для вычисления рабочего времени

Решение, которое я предлагаю, ищет на каждый «выход» соответствующий ему «вход».

select tp1.punch_time - tp2.punch_time as time_worked

from time_punch tp1

join time_punch tp2

on tp2.id = (

  select tps.id

  from time_punch tps

  where tps.id < tp1.id

  and tps.employee_id = tp1.employee_id

  and not tps.is_out_punch

  order by tps.id desc limit 1

)

where tp1.employee_id = 1 and tp1.is_out_punch;


time_worked

2

-------------

3

01:30:00 (1 row)

В этом запросе я выбираю все выходы, затем я соединяю их с наиболее близким «входом». Беру разность временных меток и получаю количество часов, которое отработал Bear в каждой смене!

Одна из проблем в этой схеме состоит в том, что возможно вставить несколько «входов» или «выходов» подряд. С созданным запросом это приведет к неоднозначности, которая может привести к неточным расчетам и зарплате сотрудников — тбольше или меньше, чем они должны были бы получить.

Пример триггера INSERT BEFORE: сохранение целостности данных

Нам требуется то, что не позволит нарушить шаблон вход/выход. К сожалению, ограничения check только отслеживают вставляемую или обновляемую строку и не могут учитывать данные из других строк.

Это идеальная ситуация для использования триггера баз данных!

Давайте создадим триггер для предотвращения события INSERT, которое нарушает наш шаблон. Сначала мы создадим «триггерную функцию». Эта функция есть то, что будет выполнять триггер при наступлении события.

Триггерная функция создается как обычная функция PostgreSQL за тем исключением, что возвращает триггер.

create or replace function fn_check_time_punch() returns trigger as $psql$

    begin

        if new.is_out_punch = (

          select tps.is_out_punch

          from time_punch tps

          where tps.employee_id = new.employee_id

          order by tps.id desc limit 1

        ) then

            return null;

        end if;

        return new;

    end;

$psql$ language plpgsql;

Ключевое слово new представляет значения вставляемой строки. Это также объект, который вы можете вернуть, чтобы позволить продолжиться вставке. Напротив, возвращение null остановит вставку.

Этот запрос сначала находит в time_punch предыдущее значение и гарантирует, что это значение входа/выхода не совпадает с вставляемым значением. Если значения совпадают, то триггер возвращает null, и time_punch не записывается. В противном случае, триггер возвращает new и оператор insert продолжается.

Теперь мы привяжем функцию в качестве триггера к таблице time_punch. BEFORE здесь ключевой момент. Если мы выполним этот триггер как триггер AFTER, он будет выполнен слишком поздно, чтобы остановить вставку.

create trigger check_time_punch before insert on time_punch

for each row execute procedure fn_check_time_punch(); 

Давайте попробуем вставить еще один «выход»:

insert into time_punch (employee_id, is_out_punch, punch_time)

values

(1, true, '2020-01-01 13:00:00');


Output: INSERT 0 0

Как можно видеть по выводу, триггер предотвратил вставку двух последовательных выходов для одного и того же сотрудника.

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

Пример триггера в PostgreSQL #2: создание таблицы аудита

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

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

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

Я буду использовать нашу таблицу time_punch для демонстрации создания и автоматического обновления таблицы аудита с помощью триггеров.

Создание таблицы аудита

create table time_punch_audit (

  id serial primary key,

  change_time timestamp not null default now(),

  change_employee_id int not null references employee(id),

  time_punch_id int not null references time_punch(id),

  punch_time timestamp not null

);

В эту таблицу записывается:

• Время обновления прохождения.
• Сотрудник, который выполнил обновление.
• ID прохода, который был изменен.
• Время прохода до того, как было сделано обновление.

Прежде чем создавать триггер, сначала нам нужно добавить столбец change_employee_id в таблицу time_punch. Тогда триггер будет знать, какой сотрудник сделал каждое изменение в таблице time_punch.

alter table time_punch 

add column change_employee_id int null references employee(id);

(Как альтернативное решение без добавления каких-либо столбцов в time_punch, можно аннулировать права update на эту таблицу и заставить пользователей базы данных использовать пользовательскую функцию типа update_time_punch(id, change_user_id, …))

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

create or replace function fn_change_time_punch_audit() returns trigger as $psql$

  begin

    insert into time_punch_audit (change_time, change_employee_id, time_punch_id, punch_time)

    values

        (now(), new.change_employee_id, new.id, old.punch_time);

    return new;

  end;

$psql$ language plpgsql;


create trigger change_time_punch_audit after update on time_punch

for each row execute procedure fn_change_time_punch_audit();

Функция NOW() возвращает текущую дату и время с точки зрения сервера SQL. Если бы это было привязано к настоящему приложению, вы, вероятно, захотели бы передавать точное время, когда пользователь фактически сделал запрос, чтобы избежать расхождения из-за задержки.

Для триггера на обновление объект NEW представляет те значения, которые будут содержаться
в строке при успешном обновлении. Вы можете использовать триггер для «перехвата» вставки или обновления простым присвоением своих собственных значений в объект NEW. Объект OLD содержит значения строки до обновления.

Проверим, работает ли это! Я добавил второго пользователя с именем Daniel, который будет редактором времени прохода Bear.

select punch_time

from time_punch

where id=2;


    punch_time      

---------------------

 2020-01-01 11:30:00

(1 row)

Я собираюсь выполнить дважды нижеприведенный запрос для имитации 2 редакций, которые увеличивают время на 5 минут.

update time_punch 

set punch_time = punch_time + interval '5 minute', change_employee_id = 2 

where id = 2;

А вот таблица аудита, отражающая прошлые времена прохода:

Дополнительные сообщажения относительно триггеров

Вот несколько вещей, связанные с триггерами, которые следует иметь в виду:

1. Обслуживание триггеров с течением времени.
2. Связанная логика триггера.
3. Опыт разработчиков.

Обслуживание триггеров с течением времени

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

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

Связанная логика триггера

Триггеры также могут запускать другие триггеры, быстро усложняя результаты казалось бы невинных INSERT или UPDATE. Этот риск также может привести к побочным эффектам кода приложения.

Опыт разработчиков

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

Изначально SQL может показаться неуклюжим и неудобным языком для изучения, поскольку многие из шаблонов, которые вы изучаете для построения запроса, «вывернуты наизнанку» по сравнению с тем, как вы извлекаете данные на процедурном языке.

Я надеюсь, что у вас появится возможность изучить и реализовать одну из самых увлекательных и интригующих функций SQL!

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

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

Перенесемся на 16 лет вперед, и теперь я могу видеть с точки зрения моего брата. В мире разработки полного стека в стиле стартапов с открытым исходным кодом (например, Django, Rails, Javascript, PHP, MySQL, Postgres…) ORM очень популярны, а такие функции, как триггеры SQL, гораздо менее традиционны.

Но все еще есть ценность с триггерами SQL. Когда я работал над заказным программным обеспечением, подобным ERP, триггеры SQL были бесценным инструментом. При создании программного обеспечения, ориентированного на данные, особенно когда данные имеют финансовый характер и требуется высокая точность, вы, скорее всего, увидите, что данные манипулируются на более низком уровне более прямым способом.

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

Оглавление

• Что такое SQL-триггер?
• Как создать триггер SQL — синтаксис
• Пример 1 триггера Postgres: создание часов
• Пример 2 триггера Postgres: создание таблицы аудита
• Дополнительные соображения по триггерам

Что такое триггер SQL?

Триггеры SQL, также называемые триггерами базы данных, позволяют указать механизму SQL (в данном случае Postgres) выполнять фрагмент кода, когда происходит событие или даже до него.

В Postgres вы определяете код для запуска, создавая функцию с типом возвращаемого значения trigger. В некоторых других движках, таких как MySQL, блок кода является частью триггера и находится внутри него.

Прежде чем я расскажу о различных типах событий и конкретном синтаксисе для создания триггера, почему вы хотите использовать триггер базы данных?

Преимущества использования триггеров SQL

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

Разделение бизнес-логики. Кодирование критической бизнес-логики в коде приложения также создает проблемы при обновлении бизнес-логики. Если бы у вас было бизнес-требование умножить входящее число на 10, и вы хотели бы пересмотреть эту логику, чтобы умножить число на 20, изменение логики в SQL гарантировало бы, что каждый фрагмент данных с этого точного времени развертывания будет затронут новая логика.

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

Атомарные транзакции. Естественная атомарность — еще одна желательная функция, связанная с триггерами. Поскольку событие и триггерная функция являются частью одной атомарной транзакции, вы с абсолютной уверенностью знаете, что триггер сработает, если сработает событие. Они как одно целое, в идеальном SQL-супружестве.

Как создать триггер SQL — синтаксис Postgres

Вот компоненты для создания триггера для вашей базы данных:

1. Тип триггерного события
2. До или после события
3. Эффект триггера

Типы триггерных событий

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

• Изменение данных: INSERT, UPDATE, DELETE

Триггер базы данных также может отображать более одного из этих событий.

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

Триггер BEFORE или AFTER

Триггер может запустить BEFORE или AFTER событие.

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

Эффект триггера

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

Если в триггере указать FOR EACH ROW, то триггер сработает 5 раз. Если вы укажете FOR EACH STATEMENT, то он запустится только один раз.

И, конечно же, мы не можем забыть код, который запускается при активации триггера. В Postgres помещается в функцию и отделяется от триггера. Отделение триггера от кода, который он запускает, создает более чистый код и позволяет нескольким триггерам выполнять один и тот же код.

Пример триггера Postgres № 1: создание часов

Табель учета рабочего времени фиксирует приход и уход сотрудника с работы и подсчитывает общее количество отработанных им часов. Давайте создадим пример часов и посмотрим, как мы можем использовать триггеры, чтобы предотвратить ввод сотрудниками неверных данных.

Настройка схемы БД

Дизайн этой схемы рассматривает каждое включение и выключение как отдельные события. Каждое событие представляет собой строку в таблице time_punch. Кроме того, вы также можете сделать «смену» каждого сотрудника событием и сохранить время начала и окончания работы в одной строке.

В этом примере я пошел дальше и определил схему для наших таблиц. Приведенный ниже код создает таблицу employee и time_punch и вставляет некоторые данные об отметке времени для нового сотрудника Bear.

create table employee (
  id serial primary key,
  username varchar
);

create table time_punch (
  id serial primary key,
  employee_id int not null references employee(id),
  is_out_punch boolean not null default false,
  punch_time timestamp not null default now()
);

insert into employee (username) values ('Bear');
insert into time_punch (employee_id, is_out_punch, punch_time)
values
(1, false, '2020-01-01 10:00:00'),
(1, true, '2020-01-01 11:30:00');

Медведь пришел в 10:00 и ушел в 11:30 (долгий рабочий день). Давайте напишем SQL-запрос, чтобы вычислить, как долго Медведь работал.

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

Использование SQL для расчета отработанного времени

Решение, которое я выбрал, рассматривает каждый удар «наружу» и сопоставляет его с предыдущим ударом «внутрь».

select tp1.punch_time - tp2.punch_time as time_worked
from time_punch tp1
join time_punch tp2
on tp2.id = (
	select tps.id
	from time_punch tps
	where tps.id < tp1.id
	and tps.employee_id = tp1.employee_id
	and not tps.is_out_punch
	order by tps.id desc limit 1
)
where tp1.employee_id = 1
and tp1.is_out_punch
time_worked
-------------
 01:30:00
(1 row)

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

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

Пример триггера SQL INSERT BEFORE — сохранение целостности данных

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

Это идеальная ситуация для использования триггера базы данных!

Давайте создадим триггер для предотвращения события INSERT, которое нарушит наш шаблон. Сначала мы создадим «триггерную функцию». Эта функция — то, что триггер будет выполнять при обнаружении типа события.

Триггерная функция создается как обычная функция Postgres, за исключением того, что она возвращает trigger.

create or replace function fn_check_time_punch() returns trigger as $psql$
  begin
    if new.is_out_punch = (
      select tps.is_out_punch
      from time_punch tps
      where tps.employee_id = new.employee_id
      order by tps.id desc limit 1
    ) then
      return null;
    end if;
    return new;
  end;
$psql$ language plpgsql;

Ключевое слово new представляет значения вставляемой строки. Это также объект, который вы можете вернуть, чтобы продолжить вставку. В качестве альтернативы, когда возвращается null, вставка останавливается.

Этот запрос находит time_punch раньше и гарантирует, что его входное/исходное значение не совпадает с тем, что вставляется. Если значения совпадают, триггер возвращает null и time_punch не записывается. В противном случае триггер возвращает new, и оператор insert может продолжить работу.

Теперь мы свяжем функцию как триггер с таблицей time_punch. BEFORE имеет решающее значение здесь. Если бы мы запустили этот триггер как триггер AFTER, он запустился бы слишком поздно, чтобы остановить вставку.

create trigger check_time_punch before insert on time_punch for each row execute procedure fn_check_time_punch();

Попробуем вставить еще один удар «вне»:

insert into time_punch (employee_id, is_out_punch, punch_time)
values
(1, true, '2020-01-01 13:00:00');
Output:
INSERT 0 0

Из вывода видно, что триггер предотвратил вставку двух последовательных выходов для одного и того же сотрудника.

Также можно вызвать исключение из триггера, чтобы ваше приложение (или человек, выполняющий SQL-запрос) получало уведомление об ошибке, а не количество вставок, просто равное 0.

Пример триггера Postgres № 2: создание таблицы аудита

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

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

Таблица аудита выполняет это, отслеживая каждое изменение в таблице. Когда строка обновляется в основной таблице, строка будет вставлена ​​в таблицу аудита, в которой будет записано ее прошлое состояние.

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

Создайте таблицу аудита

Существует несколько способов ведения таблицы аудита или истории. Создадим отдельную таблицу, в которой будут храниться прошлые состояния time_punch.

create table time_punch_audit (
  id serial primary key,
  change_time timestamp not null default now(),
  change_employee_id int not null references employee(id),
  time_punch_id int not null references time_punch(id),
  punch_time timestamp not null
);

В этой таблице хранятся:

• Время обновления пунша
• Сотрудник, обновивший его
• ID пуансона, который был изменен
• Время перфорации до обновления перфорации

Прежде чем мы создадим наш триггер, нам сначала нужно добавить столбец change_employee_id в нашу таблицу time_punch. Таким образом, триггер будет знать, какой сотрудник внес каждое изменение в таблицу time_punch.

alter table time_punch add column change_employee_id int null references employee(id);

(Альтернативное решение без добавления каких-либо столбцов в time_punch может состоять в том, чтобы отозвать разрешение на обновление этой таблицы и заставить пользователей этой базы данных использовать пользовательскую функцию, например update_time_punch(id, change_user_id, ...))

Пример триггера SQL UPDATE AFTER — вставка данных

После обновления нашего time_punch table этот триггер запускается и сохраняет значение времени пунша OLD в нашей таблице аудита.

create or replace function fn_change_time_punch_audit() returns trigger as $psql$
  begin
    insert into time_punch_audit (change_time, change_employee_id, time_punch_id, punch_time)
    values
    	(now(), new.change_employee_id, new.id, old.punch_time);
    return new;
  end;
$psql$ language plpgsql;
create trigger change_time_punch_audit after update on time_punch
for each row execute procedure fn_change_time_punch_audit();

Функция NOW() возвращает текущую дату и время с точки зрения сервера SQL. Если бы это было связано с реальным приложением, вы бы хотели рассмотреть возможность передачи точного времени, когда пользователь фактически сделал запрос, чтобы избежать расхождений из-за задержки.

Во время триггера обновления объект NEW представляет, какие значения будет содержать строка в случае успешного обновления. Вы можете использовать триггер для «перехвата» вставки или обновления, просто назначив свои собственные значения объекту NEW. Объект OLD содержит значения строки перед обновлением.

Посмотрим, работает ли это! Я добавил второго пользователя по имени Даниэль, который будет редактором тайм-панчей Медведя.

select punch_time
from time_punch
where id=2;
punch_time      
---------------------
 2020-01-01 11:30:00
(1 row)

Я собираюсь запустить запрос ниже дважды, чтобы смоделировать 2 редактирования, которые увеличат время на 5 минут.

update time_punch set punch_time = punch_time + interval '5 minute', change_employee_id = 2 where id = 2;

А вот таблица аудита, отражающая прошлые времена ударов:

change_time         | username |     punch_time      
----------------------------+----------+---------------------
 2021-01-06 20:10:56.44116  | Daniel   | 2020-01-01 11:35:00
 2021-01-06 20:10:55.133855 | Daniel   | 2020-01-01 11:30:00

Дополнительные сведения о триггерах

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

1. Поддержание триггеров с течением времени
2. Логика подключенного триггера
3. Опыт разработчиков

Поддержание триггеров с течением времени. Бизнес-логика в коде приложения, естественно, документируется, поскольку она изменяется с течением времени посредством git или другой системы контроля версий. Разработчику легко увидеть некоторую логику в кодовой базе, сделать быстрый git log и увидеть список изменений.

Управление изменениями с течением времени с помощью триггеров и функций SQL является более сложным, менее стандартизированным и требует большего внимания и планирования.

Подключенная логика триггера. Триггеры также могут запускать другие триггеры, быстро усложняя результаты того, что может показаться невинным INSERT или UPDATE. Этот риск также присущ коду приложения с побочными эффектами.

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

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

Использование триггеров для повышения уровня вашей игры в SQL

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

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

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

Триггеры — это объекты базы данных в SQL Server. Технически они представляют собой особый класс вызовов функций, которые реагируют на определенные операции с базой данных.

Это важное руководство предоставит вам подробную информацию о триггерах SQL, которая может оказаться весьма полезной в вашей профессии. Давайте начнем!

Слово «триггер» описывает утверждение, что сервер автоматически выполняет запрос каждый раз, когда содержимое базы данных изменяется.

Триггер — это группа SQL-запросов со специальными именами, которые хранятся в памяти. Это особый тип вызова функции, который немедленно вызывается всякий раз, когда происходит какое-либо событие базы данных. Каждому триггеру назначена таблица.

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

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

Синтаксис:

CREATE TRIGGER trigger_name
BEFORE/AFTER
INSERT/UPDATE/DELETE
ON tableName
FOR EACH ROW SET operation [trigger_body];

Объяснение каждого параметра

• CREATE TRIGGER trigger_name — используется для создания триггера или для изменения имени существующего триггера.
• ДО/ПОСЛЕ — этот запрос используется для определения времени выполнения триггера (до или после определенного события).
• INSERT/UPDATE/DELETE — описывает действие, которое мы хотим выполнить над таблицами.
• ON tableName — здесь мы определяем имя таблицы для настройки триггера.
• ДЛЯ КАЖДОЙ СТРОКИ — этот оператор относится к триггеру строки, что означает, что триггеры будут выполняться всякий раз, когда строка изменяется.
• trigger_body — указывает действие, которое должно быть выполнено при срабатывании триггера.

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

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

Ниже приведены некоторые преимущества использования триггеров в операциях базы данных SQL.

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

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

Комбинация триггерных аргументов

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

BEFORE INSERT: Эти триггеры выполняют действие над строками перед выполнением любых операций INSERT в указанной таблице или в базе данных.

ПОСЛЕ ВСТАВКИ: он выполняет действие над строками сразу после любого действия INSERT базы данных.

ПЕРЕД ОБНОВЛЕНИЕМ: с помощью этих триггеров функция в строках выполняется до выполнения действия ОБНОВЛЕНИЕ в базе данных.

ПОСЛЕ ОБНОВЛЕНИЯ: он выполняет действие над строками сразу после любого действия ОБНОВЛЕНИЯ базы данных или конкретной таблицы.

ПЕРЕД УДАЛЕНИЕМ: он выполняет определенную операцию над строками еще до того, как база данных или таблица будут подвергнуты действию DELETE.

ПОСЛЕ УДАЛЕНИЯ: Эти триггеры выполняют действие над строками после каждой транзакции УДАЛЕНИЯ.

Типы триггеров SQL

Триггеры SQL — это сохраненные функции, которые запускаются немедленно при возникновении определенных событий. Это напоминает планирование, управляемое событиями. Последующие ситуации могут запускать выполнение триггеров.

Триггеры DML — DML расшифровывается как язык манипулирования данными. Выполнение кода в ответ на изменение данных стало возможным с помощью триггеров DML. Этот триггер активируется при выполнении команд DML, таких как INSERT, UPDATE и DELETE. Их также называют «триггерами уровня таблицы».

Триггеры DDL — DDL означает язык определения данных. Триггеры DDL позволяют нам запускать код в ответ на изменения схемы базы данных, такие как добавление или удаление таблиц, или события сервера, такие как регистрация пользователя. Они называются «триггерами уровня базы данных».

Эти триггеры можно активировать, когда определенные операторы DDL, такие как CREATE, ALTER или DROP, выполняются в активной базе данных. Их также можно использовать для наблюдения и управления выполняемыми действиями.

Триггеры входа в систему — всякий раз, когда происходит какое-либо событие входа в систему (запуск, вход в систему, выход из системы, завершение работы), немедленно активируются триггеры входа в систему. Они выполняются только после процесса аутентификации пользователя, даже до того, как транзакция пользователя будет инициирована. Триггеры LOGON не сработают в случае сбоя авторизации.

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

Триггеры CLR — CLR расшифровывается как Common Language Runtime. Триггеры CLR действительно представляют собой уникальное подмножество триггеров, построенных в основном на CLR в рамках технологии .NET. Эти триггеры полезны, если триггеру необходимо выполнить множество вычислений или он должен быть связан с сущностью, отличной от SQL.

Триггеры DML и DDL действительно можно создать, включив кодирование поддерживаемых триггеров CLR в технологиях .NET, включая Visual Basic, C# и F-sharp.

Пример триггера SQL Server

Давайте разберемся с этими концепциями триггеров на примере.

Во-первых, давайте создадим базу данных с помощью операторов SQL.

CREATE DATABASE testdb;
use testdb;

Здесь я дал «testdb» в качестве имени базы данных. И следующим шагом будет создание таблицы.

CREATE TABLE student(
  name varchar(25),
  id int(2),
  maths int(2),
  physics int(2),
  biology int(2),
  social int(2),
  total int(2)
 );

Я создал таблицу для хранения данных о студентах. А вот и команда для описания структуры таблицы. Здесь «студент» — это имя таблицы, которое я дал.

DESC student;

Ниже представлена ​​структура таблицы, которую я создал.

+---------+-------------+------+-----+---------+-------+
| Field   | Type        | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| name    | varchar(25) | YES  |     | NULL    |       |
| id      | int         | YES  |     | NULL    |       |
| maths   | int         | YES  |     | NULL    |       |
| physics | int         | YES  |     | NULL    |       |
| biology | int         | YES  |     | NULL    |       |
| social  | int         | YES  |     | NULL    |       |
| total   | int         | YES  |     | NULL    |       |
+---------+-------------+------+-----+---------+-------+
7 rows in set (0.00 sec)

После создания таблицы следующим шагом будет настройка триггера. Давайте попробуем использовать аргумент BEFORE INSERT.

Название созданного мной триггера — «метки». Как только в таблицу вносятся оценки учащегося, нижеприведенный триггер пытается автоматически определить общую оценку учащегося.

CREATE TRIGGER marks
BEFORE INSERT
ON
student
FOR EACH ROW
set new.total=new.maths+new.physics+new.biology+new.social;

Поскольку нам требуется заменить данные строк, а не работать со старыми, мы определили «итого» с помощью нового имени класса, а все последующие выражения имеют префикс с новыми ключевыми словами после итога с помощью оператора точки. Теперь мы добавим значения в каждую строку и посмотрим на результаты. Изначально общая оценка равна 0 для каждого ученика.

INSERT INTO student VALUES("George",02,99,87,92,91,0);
INSERT INTO student VALUES("James",03,91,81,94,90,0);
INSERT INTO student VALUES("Harry",04,86,70,73,88,0);
INSERT INTO student VALUES("John",05,73,89,78,92,0);
INSERT INTO student VALUES("Lisa",01,94,75,69,79,0);

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

SELECT * FROM table_name;

И вот окончательный вывод.

mysql> select * from student;
+--------+------+-------+---------+---------+--------+-------+
| name   | id   | maths | physics | biology | social | total |
+--------+------+-------+---------+---------+--------+-------+
| George |    2 |    91 |      81 |      94 |     90 |   356 |
| James  |    3 |    86 |      70 |      73 |     88 |   317 |
| Harry  |    4 |    73 |      89 |      78 |     92 |   332 |
| John   |    5 |    94 |      75 |      69 |     79 |   317 |
| Lisa   |    1 |    99 |      87 |      92 |     91 |   369 |
+--------+------+-------+---------+---------+--------+-------+
5 rows in set (0.00 sec)

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

Дополнительные триггерные операции

Мы можем выполнять множество операций с помощью триггеров. Некоторые из них могут быть простыми, а некоторые могут быть немного сложными, но как только мы пройдемся по запросам, их будет легко понять. Используя операторы Transact-SQL, вы можете включать, отключать или удалять триггеры с помощью следующих команд.

Запрос, чтобы проверить, существует ли конкретный триггер или нет

Эта команда проверяет указанный триггер во всей базе данных.

SELECT * FROM [sys].[triggers] WHERE [name] = 'Trigger_name'

Запрос для отображения триггеров

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

SHOW TRIGGERS;

Запрос на отключение триггера

Приведенная ниже команда деактивирует триггер в рабочей базе данных.

DISABLE TRIGGER trigger_name ON DATABASE;

Вы также можете указать определенное имя таблицы, чтобы отключить триггер.

DISABLE TRIGGER trigger_name ON table_name;

Запрос для включения триггера

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

ALTER TABLE table_name DISABLE TRIGGER trigger_name

ALTER TABLE table_name ENABLE TRIGGER trigger_name

Триггер должен быть отключен, прежде чем пытаться его включить,

Запрос для включения или отключения всех триггеров в таблице

Используя приведенный выше оператор SQL, мы можем деактивировать или активировать все триггеры таблицы одновременно, подставив «ALL» вместо определенного имени триггера.

ALTER TABLE table_name DISABLE TRIGGER ALL 

ALTER TABLE table_name ENABLE TRIGGER ALL

Запрос на удаление или удаление триггера

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

DROP TRIGGER [trigger_name];

Всякий раз, когда триггер удаляется, связанные с ним данные удаляются из таблицы данных sys.objects.

Преимущества триггеров

• Создать триггеры просто, и сам триггер может вызывать сохраненные функции и методы.
• Пользователи могут реализовать простой аудит с помощью триггеров.
• К сожалению, вы не можете создавать ограничения для сущностей в системах баз данных с помощью SQL Server, хотя вы можете эмулировать действие ограничений, используя триггеры.
• Ограничения целостности могут быть реализованы в базах данных с помощью триггеров.
• Когда требуется групповая проверка, а не построчная проверка вновь введенных или измененных данных, могут быть полезны триггеры.

Недостатки триггеров

Триггеры SQL могут быть не лучшим выбором в некоторых ситуациях из-за их ограничений.

• Триггеры должны быть точно задокументированы.
• Из-за одновременного выполнения базы данных, которая может быть недоступна для компонентов приложения, отладка триггеров может быть сложной.
• Операторы DML усложняются при использовании триггеров.
• Даже незначительная проблема с триггером может привести к логическим ошибкам в заявлении.

Вывод

Триггеры — очень полезные компоненты Transact-SQL и SQL, и их можно использовать и в Oracle. Использование триггеров имеет решающее значение при вызове хранимых методов. Эти триггеры SQL позволяют нам анализировать временные рамки активности и определять, как реагировать на них, если это необходимо. Мы также можем проверить наличие определенной таблицы, которая подключена к триггеру для получения данных.

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

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

Я надеюсь, что вы нашли эту статью полезной для изучения триггеров SQL.

Если вы хотите подробно изучить базы данных, вот несколько отличных ресурсов для изучения SQL и NoSQL.

# Триггеры

Триггеры предоставляют самый мощный функционал в боте. Вы можете настроить любую реакцию на любое сообщение пользователей.

Желать доброго утра админам (или любым конкретным пользователям), по утрам, если они зайдут в беседу? – Не вопрос.

При отправке пользователями gif’ок вежливо попросить её удалить в течение минуты, и если он это не сделает – удалить гифку и выдать предупреждение, а если сделает – написать «спасибо за понимание»? – Пожалуйста.

Отправлять в чат «Хозяин, вас звали!» с ссылкой на ваш профиль, когда вас упоминают в группе? – Да, и такое возможно.

Основная функция триггера – определенное УСЛОВИЕ, и при его выполнении, происходит определенное ДЕЙСТВИЕ, которое вы задаете сами.

# Тарифы на триггеры

Данная таблица рассказывает о различиях тарифов на триггеры. Лимита на группы условий/группы действий нет – вы можете создать 6 групп действий, в каждой из которой будет по одному действию, или 1 группу действий с шестью действиями для тарифа «Starter».

Если вы выйдете за лимиты триггера или истечет срок тарифа – (появится красная надпись, уведомляющая о том, что превышено количество триггеров или действий в них) триггеры будут работать, с ограничениями. Например, если вы создали 4 действия без тарифа, работать будут три. Также и количество триггеров – если будет больше, чем возможно, остальные просто не будут работать.

# Навигация по триггерам

Заходим в раздел «Триггеры чата», нажимаем на «+ Добавить новый»

Далее, выйдет окно с условиями создания триггера:

Задаем название триггеру.

# Тип выполнения триггера

«Выполнить все действие» — это значит, что за определенное условие, будет выполнены все указанные и заданные вами далее действия. (В том случае, если вы укажете несколько действий)

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

«Условия» — это определенные сообщения, слова, смайлы, после совершения которых применяются определенные действия.

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

# Отработка триггеров

Отработка триггеров происходит поочередности.
На картинке ниже выделен красным номер, по которым идет очередь срабатывания триггеров

Чтобы триггеры работали подряд по порядку необходимо включить тумблер «Продолжить выполнение цепи триггера по окончании текущего триггера» в расширенных настройках, доступных с тарифа «Advanced»

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

# Условия триггеров

Создаем условия с помощью «+», открывается отдельное окно «Группа условий» и снизу отдельная кнопка «+». Нажимая на отдельную кнопку, создается еще одна группа условий с отдельными функциями.

# Типы условия:

Всего 18 условий, 4 инициатора, 8 типов сообщений и 6 фильтров для условий на текст сообщения.

# Полное совпадение

Триггер сработает при полном совпадении сообщения с указанным Вами значением в условии. То есть, если укажете в условии «Привет», условие выполнится только при сообщении «Привет». Если будет «Привет. Знаешь…», или «Привет.», или «Привет)» условие НЕ выполнится. *Исключение в том случае, если включить фильтр «Не учитавать символы» ниже, тогда последние два варианта бот пропустит.

# Сообщение начинается с

Триггер сработает, если сообщение пользователя будет начинаться со строк (слов/выражений), указанных вами в значениях условия. Пример: в значених «Ты». Условие сработает на сообщения: «Ты – самый вредный!», «Тыквы полезные!», «Ты123абв»

# Сообщение заканчивается на

Триггер сработает, если сообщение пользователя будет заканчиваться строками (словами/выражениями), указанными вами в значениях условия, иначе триггер не сработает. Аналогично: если в условии «ейка», оно сработает на «лейка», «абвгдейка».

# Сообщение содержит

Триггер сработает, если в сообщении будет присутствовать хоть одна из строк (слов/выражений), указанных в значениях условий. Укажете «лето» — сработает на «Какое лето жаркое!», «В кассе билетов нет!»

# Регулярное выражение

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

Выполняет поиск на основе регулярного выражения языка Java. Тестер и краткий справочник по регулярным выражениям доступен по нажатию кнопки «Помощь» в верхней панели. Также есть небольшая статья, посвященная регулярным выражениям в инструкции.

# Длина сообщения меньше или равна

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

# Длина сообщения больше или равна

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

# Тип сообщения

Доступно 13 видов сообщений, выберите те, на которые сработает триггер. Например, если поставить фото, то каждый раз когда участники будут присылать фото, условие будет выполняться.

# Регулярное выражение на меньшинах в сообщениях

Регулярное выражение, срабатывающее на логин (@username), написанный в чат в сообщениях пользователей. Значения указывать так: (username), обязательно в нижнем регистре. О работе с регулярными выражениями можно ознакомиться в инструкции. Тестер и краткий справочник по регулярным выражениям доступен по нажатию кнопки «Помощь» в верхней панели.

# Регулярное выражение на текстовых меньшинах в сообщениях

В официальном клиенте Telegram’а при написании символа «@» в чат появляется список недавних участников:

Если юзернейм у пользователя есть, то кликнув по пользователю вы получите его @username. Если юзернейма нет, то по клику вы получите его кликабельный никнейм. Например, ник пользователя – Tania Pupkina. У вас после нажатия будет слово Tania с ссылкой на её профиль. Вот это условие срабатывает на такие слова. В значениях указывать это слово (например Tania), оформленное как регулярное выражение, например «(Tania)». О работе с регулярными выражениями можно ознакомиться в инструкции. Тестер и краткий справочник по регулярным выражениям доступен по нажатию кнопки «Помощь» в верхней панели.

# Регулярное выражение на номерах телефонов

Срабатывает на номер телефона (оформленный как регулярное выражение), на который был зарегистрирован аккаунт Telegram. Телефонный номер указывать в международном формате без плюса. Возможно использовать только когда пользователь отправил свои контакты боту.

# Язык клиента

Условие на основе выбранного языка клиента Telegram (установленный язык в приложении Telegram). Значения указывать по типу: ru, en, ua. Ввиду особенностей Telegram’а, если в приложении выставлен язык русский, срабатывает на значения en и ru, поэтому будьте аккуратны с этим. Со значениями, которые можно указывать в качестве языка клиента, Вы можете ознакомиться здесь.

# Регулярное выражение на логине пользователя

Возможность сделать срабатывание условия для конкретного пользователя по его юзернейму. Обычно работает в сочетаниях с другими условиями в одной группе действий. Значения указываются таким образом: ^(username1)$, ^(username2)$ ИЛИ ^(username1|username2)$, обязательно в нижнем регистре. О работе с регулярными выражениями можно ознакомиться в инструкции. Тестер и краткий справочник по регулярным выражениям доступен по нажатию кнопки «Помощь» в верхней панели.

# Минимальная длина логина

Можете указать минимальное количество символов которое будет содержаться в логине пользователя (@username пользователя). Если логин будет содержать меньше указанных вами символов, сработает действие. Минимально возможная длина логина в Telegram – 5, максимально возможная – 32.

# Максимальная длина логина

Можете указать максимальное количество символов которое будет содержаться в логине пользователя. Если логин будет содержать больше символов что вы указали, то сработает действие. Минимально возможная длина логина в Telegram – 5, максимально возможная – 32.

# Регулярное выражение на имени пользователя

Возможность сделать условие для конкретного пользователя по его никнейму. Обычно работает в сочетаниях с другими условиями в одной группе действий. Значения указываются таким образом: ^(ник этого пользователя)$ ИЛИ ^(имя1 фамилия1|имя2 фамилия2)$, обязательно в нижнем регистре. О работе с регулярными выражениями можно ознакомиться в инструкции. Тестер и краткий справочник по регулярным выражениям доступен по нажатию кнопки «Помощь» в верхней панели.

# Минимальная длина имени

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

# Максимальная длина имени

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

# Ранг пользователя соответствует

Укажите желаемое количество рангов и на участника с соответствующими рангами сработает триггер.

# Ранг пользователя ниже

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

# Ранг пользователя выше

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

Ранг – это текущий статус участника в чате. Ранги даются за выполнение определенных действий, которые устанавливает администратор чата.

# Следующий инструмент «Фильтр условия»

Рассмотрим подробнее:

1. Не учитывать пробелы в начале и в конце строки — вне зависимости от того, будут или нет пробелы в начале или в конце строки в сообщении пользователя, триггер сработает.
2. Не учитывать пробелы и переносы строк — вне зависимости от того, как и где стоят пробелы и переносы в сообщении пользователя, триггер сработает. Например, с условием «Сообщение содержит», при включенном фильтре, если в значениях указать «громила», триггер сработает на: «Полный погроми ладно – потом уберу»
3. Не учитывать все пробелы — условие выполнится вне зависимости от того, как и где стоят пробелы в сообщении пользователя. Например, с условием «Сообщение содержит», при включенном фильтре, если в значениях указать «перламутр», сработает на «Спер лам утром», но не будет работать с переносами, как в пункте (2)
4. Не учитывать символы — условие сработает, даже если будут использованы символы, которые вы не указали в условии. Укажете в значениях «свет» — триггер сработает на «с()вет»
5. Не учитывать цифры — триггер сработает даже если будут использованы цифры, которые вы не указали в условии. В значениях «пора» — сработает на «по95ра»
6. Не учитывать регистр — триггер сработает вне зависимости от регистра (большие и маленькие буквы будут восприниматься одинаково). Пример: «Привет» в значениях сработает на «привет», «ПРИВЕТ», «пРиВеТ», и так далее.

# Инструмент «Инициатор триггера»

Инициатор триггера – участник группы, на которого будет срабатывать триггер.

• Кто угодно – условие сработает на всех участников группы
• Администраторы – условие сработает на всех администраторов, включая создателя
• Пользователи – условие сработает на всех пользователей, кроме администраторов
• Создатель – условие сработает только на создателя

# Инструмент «Тип сообщения»

Любое – условие сработает при любом сообщении;

Все реплаи – условие сработает только на реплаи (ответы);

Реплаи к боту – условие сработает только на ответы ботов;

Реплаи к пользователю – условие сработает только на ответы пользователей, кроме администраторов;

Реплаи к админу – условие сработает только на ответы администраторов;

Реплаи к @ChatKeeperBot – условие сработает на ответы к сообщениям от @ChatKeeperBot;

Не реплай – условие сработает на сообщения, которые были отправлены не реплаем (ответом);

Первое сообщение пользователя – условие сработает при первом сообщении нового участника.

# Инструмент «Инвертирование»

Инвертирование меняет все условия на обратные. Если условие должно было сработать на слово «Привет» — условие будет работать на все сообщения, в которых нет этого слова. Если стоит «Реплаи к @ChatKeeperBot» – условие будет срабатывать на все сообщения, которые не являются реплаями (ответами) к @ChatKeeperBot. Не меняются при инвертировании только фильтры условий, инициатор «Кто угодно» и тип сообщения «Любое».

# Действия триггеров

• Отправить сообщение —
  При выполнении условия, будет отправлено сообщение, текст которого вы ввели в поле ввода текста, после выбора действия;

• Отправить личным сообщением —
  Бот отправит текст в личные сообщения пользователю. Список получателей такого сообщения находится после выбора действия – туда можно указать @username (можно со знаком и без, в любом регистре) или ID пользователя. Чтобы сообщение отправилось, пользователю необходимо нажать на кнопку start в личных сообщениях с ботом. *Не забывайте, что бот первым писать не может;

• Удалить пользователя из чата с возможностью вернуться —
  Пользователь будет удален из чата, но он сможет вернуться при использовании команды /kick;

• Удалить пользователя из чата на время —
  Пользователь будет удален из чата на заданный вами период времени, по истечении этого времени, у пользователя есть возможность вернуться в чат;

• Пользователь не сможет писать —
  Пользователь не сможет писать в течении заданного вами периода времени, по истечении этого периода, пользователь сможет писать, использовав команду /mute;

• Разрешить пользователю вернуться в чат —
  Пользователь может вернуться в чат, если до этого он был исключен, для возврата в чат используйте команду /unban;

• Разрешить пользователю писать —
  Пользователь сможет писать сообщения, если до этого он был заблокирован, используйте команду /unmute;

• Удалить сообщение —
  Сообщение, на которое сработал триггер будет удалено;

• Увеличить или уменьшить репутацию пользователю —
  Действие дает возможность изменить репутацию участника в положительную или отрицательную сторону. После выбора действия будет форма «Количество», в которой вы зададите прибавление или отнятие репутации;

• Изменить количество очков пользователя —
  Действие дает возможность изменить количество очков участника. После выбора действия будет форма «Количество», в которой вы зададите прибавление или отнятие очков;

• Добавить или удалить предупреждение у пользователя —
  Возможность добавить пользователю определённое количество предупреждений, работает по принципу команды /warn;

• Добавить или удалить предупреждение в триггере —
  В данном триггере можно добавить или отнять количество предупреждений. *После заданного администратором количества предупреждений, пользователь попадает в блок;

• Отправить результат формы в чат —
  (действие доступно на тарифах Advance и Ultimate)
  После того, как участник заполнил форму, результат формы отправится в чат и будет доступен для просмотра всем пользователям. После выбора действия, в поле ввода текста можно будет написать содержимое формы;

• Отправить результат формы личным сообщением — (действие доступно на тарифах Advance и Ultimate)
  После того, как участник заполнил форму, результат формы отправится в личные сообщения указанным пользователям.
  Список получателей результата указывается после выбора действия в форму «Список пользователей, которым придет результат формы».
  Указывается юзернейм без знака @ в малом регистре, например «username» или ID пользователя.
  Чтобы сообщение отправилось, пользователю необходимо нажать кнопку start в личных сообщениях с ботом.
  Таким образом, результат формы будет доступен только определённым пользователям.
  Форму можно задать в инструменте «Открыть расширенные настройки» под формой названия триггера.