Вызов Сценария PHP от триггера MySQL

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

ДОБАВЛЕНО 19.03.2014:

Я должен был добавить некоторые рассуждения раньше, но только нашел время, чтобы сделать это сейчас. Спасибо @cmc за важное замечание. Итак, триггеры PHP добавляют в ваше приложение следующие сложности:

• Добавляет определенную степень проблем безопасности в приложение (вызовы внешних сценариев PHP, настройка разрешений, возможно, настройка SELinux и т. д.), как говорит @Johan.

• Добавляет дополнительный уровень сложности в ваше приложение (чтобы понять, как работает база данных, теперь вам нужно знать как SQL, так и PHP, а не только SQL), и вам придется отлаживать PHP также, не только SQL.

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

• Добавляет дополнительный пункт анализа производительности. Каждый вызов PHP стоит дорого, так как вам нужно запустить интерпретатор, скомпилировать скрипт в байт-код, выполнить его и т. Д. Таким образом, каждый запрос, включающий этот триггер, будет выполняться медленнее. Иногда бывает сложно изолировать проблемы с производительностью запроса, поскольку EXPLAIN не Я ничего не могу сказать о том, что запрос выполняется медленнее из-за производительности процедуры запуска. И я не уверен, как время триггера записывается в журнал медленных запросов.

• Добавляет некоторые проблемы при тестировании приложений. SQL можно довольно легко протестировать. Но чтобы протестировать триггеры SQL + PHP, вам придется применить некоторые навыки.

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

Я нашел это:

http://forums.mysql.com/read.php? 99,170973,257815 # msg-257815

DELIMITER $$
CREATE TRIGGER tg1 AFTER INSERT ON `test`
FOR EACH ROW
BEGIN
\! echo "php /foo.php" >> /tmp/yourlog.txt
END $$
DELIMITER ;

Мы с другом придумали, как вызвать Бернардо Дамеле sys_eval UDF, но решение не такое элегантное, как хотелось бы. Вот что мы сделали:

1. Поскольку мы используем Windows, нам пришлось скомпилировать библиотеку UDF для Windows, используя инструкции Роланда Боумана , и установить их на нашем сервере MySQL.
2. Мы создали хранимую процедуру, которая вызывает sys_eval.
3. Мы создали триггер, который вызывает хранимую процедуру.

Код хранимой процедуры:

DELIMITER $$
CREATE PROCEDURE udfwrapper_sp
(p1   DOUBLE,
 p2   DOUBLE,
 p3 BIGINT)
BEGIN
 DECLARE cmd CHAR(255);
 DECLARE result CHAR(255);
 SET cmd = CONCAT('C:/xampp/php/php.exe -f "C:/xampp/htdocs/phpFile.php" ', p1, ' ', p2, ' ', p3);
 SET result = sys_eval(cmd);
END$$;

Код триггера:

CREATE TRIGGER udfwrapper_trigger AFTER INSERT ON sometable
FOR EACH ROW
CALL udfwrapper_sp(NEW.Column1, NEW.Column2, NEW.Column3);

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

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