Базы данных невероятно мощные. К сожалению, они имеют репутацию сложных и загадочных зверей, управляемых темными повелителями, которые говорят на странных языках. Я виновен в разработке веб-приложений, которые избегали великолепных методов работы с базами данных, которые я не понимал. Я не думаю, что я один — многие разработчики предпочитают заново изобретать колеса в PHP, а не реализовывать функциональность базы данных, которая может сэкономить время и усилия при повышении производительности.
Сегодня мы рассмотрим триггеры и события — функции, поддерживаемые большинством популярных коммерческих и открытых систем баз данных…
Триггеры
Триггер — это код, запускаемый непосредственно перед или сразу после события SQL INSERT, UPDATE или DELETE в конкретной таблице базы данных. Этот код может проверять или изменять входящие данные, выполнять вычисления, выполнять дополнительные команды SQL и т. Д.
Триггеры поддерживаются в MySQL, PostgreSQL, SQLite, Firebird, DB2, Microsoft SQL Server и Oracle. Реализация варьируется, поэтому вы должны проверить соответствующую документацию перед написанием кода.
События (или временные триггеры)
События часто называют «временными триггерами», потому что они запланированы по времени, а не по обновлению таблицы. События могут быть запланированы для запуска один или несколько раз в определенные периоды. По сути, они являются заданиями cron только для базы данных и могут использоваться для архивирования данных, очистки журналов или вычисления информации для сложных отчетов.
Меньше баз данных поддерживают события, но большинство предоставляют аналогичное решение. Не все будет легко реализовать в типичном веб-приложении, поэтому, пожалуйста, проверьте свою документацию.
Когда следует использовать триггеры?
Триггеры могут быть простыми или сложными, как вам нравится. Тем не менее, есть несколько ситуаций, в которых их следует избегать:
- Триггеры не должны использоваться вместо ограничений внешнего ключа . Внешние ключи обеспечивают ссылочную целостность, поэтому становится невозможным добавлять, удалять или редактировать данные, которые оставляют потерянные записи. Например, если вы удаляете пользователя из своей системы социальных сетей, вы не обязательно хотите, чтобы сообщения от этого человека были сохранены.
- Триггеры не заменяют транзакции . Код триггера может дать сбой, поэтому вы все равно должны обернуть связанные обновления в одну транзакцию.
- Будьте осторожны при разделении вашей бизнес-логики между базой данных и вашими внутренними системами (написано на PHP, C #, Java и т. Д.). Обслуживание станет более сложным, если ваш код отделен.
- Избегайте дублирования усилий. Ваш внутренний код должен очищать ввод данных пользователем, поэтому нет необходимости повторять эти проверки в базе данных.
- Триггеры влекут за собой снижение производительности. Они будут выполняться быстрее, чем ряд SQL-команд, переданных внутренним кодом, но вы должны воздерживаться от использования сложных триггеров в регулярно изменяемых таблицах.
В идеале триггеры следует учитывать, когда они автоматизируют изменения, которые относятся к базе данных или управлению ее данными. Журнал аудита является хорошим примером. Рассмотрим систему CMS, подобную WordPress, с таблицей блогов, содержащей заголовки и основной текст. Таблица аудита может записывать дату и время добавления, редактирования или удаления статьи. Ваша веб-система может никогда не представить эту информацию или даже знать, что она записана, поэтому триггер был бы идеальным
Наша таблица «блог» будет иметь отношение один ко многим с таблицей «аудит»; другими словами, одна или несколько записей аудита будут указывать на один пост. Предположим, что наша система хочет получить заголовок, содержание тела и дату последнего обновления, то есть само сообщение и его последнюю записанную запись в таблице «аудита». Мы можем получить эту информацию, но команда SELECT сложна и требует дополнительного выбора, чтобы гарантировать, что мы получим только последнюю запись аудита.
Триггер может помочь нам снизить сложность и повысить производительность. Например, мы могли бы добавить поле ‘last_audit_id’ в нашу таблицу ‘blog’. Всякий раз, когда сообщение обновляется, новая запись будет добавлена в таблицу аудита, а ее идентификатор будет записан в blog.last_audit_id.
Когда вы должны использовать события?
Запланированные события идеально подходят для пакетной обработки больших объемов данных в непиковые периоды.
Предположим, мы хотим удалить сообщение из нашей таблицы блогов. Вместо того, чтобы выполнять SQL DELETE, мы установили бы логическое «удаленное» поле в значение true, чтобы можно было восстановить сообщение. Через некоторое время наша таблица станет больше, медленнее и, возможно, будет содержать большую долю удаленных статей. Чтобы решить эту проблему, запланированное событие можно запускать раз в неделю для перемещения старых удаленных сообщений и записей аудита в архивные таблицы. Он также может физически удалить сообщение, когда оно достигнет определенного возраста.
Это всего лишь простые предложения, и у вашего приложения будут другие требования. К счастью, триггеры и события поддерживаются в наиболее используемой системе реляционных баз данных в Интернете: MySQL 5.x. В моих следующих статьях мы обсудим, как создать базу данных блога, аналогичную описанной выше.
Смотрите также: