Слежение за изменениями данных в MySQL при помощи PHP

[@humbug]

А как быть, если на таблице уже весит триггер?

For example, you cannot define two BEFORE INSERT triggers or two AFTER UPDATE triggers for a table.
dev.mysql.com/doc/refman/5.5/en/trigger-syntax.html

[@Aleks_ja]

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

[@weirdan]

Вижу потенциальную проблему — на слейвах порядок выполнения запросов может отличаться
Вот, кстати, о том же в умных блогах пишут: www.mysqlperformanceblog.com/2008/09/29/why-audit-logging-with-triggers-in-mysql-is-bad-for-replication/

[@Aleks_ja]

Порядок нам не так важен, как информация о том, что данные были изменены и кто за это в ответе (напрмер, какой-то баг в скрипте, либо человек).

[@TBIKC]

* бравзер?

[@spacediver]

корявовато, но симпатично :)

[@Chesnovich]

раз на то пошло, то «бровзер»

[@sl4mmer]

>Выбираем MyISAM т.к. будет много инсертов.

Неуловил логики, почему не InnoDb?

[@teonoman]

Да вот да. Майисам ведь на чтение хорош.

[@Aleks_ja]

InnoDB ведь пересчитывает индексы всё время при инсертах? По крайней мере в подсознании моём такая картина. И засекал время когда-то на инсертах.

[@sl4mmer]

Myisam при инсерте/апдейте ставит лок на всю таблицу, из-за чего при большом количестве запросов, база встает колом (т.к единовременно может проходить только один). InnoDb лочит только ту строку (строки) с которыми мы производим операции. Пересчитываю индексы оба движка, но там они по разному устроены. Объективно — иннодб, за счет механизма построчной блокировки, превосходит myisam на операция insert/update/delete

[@Aleks_ja]

Я не большой специалист по разным движкам баз данных. Я просто сделал цикл локально который вставляет огромное количество записей — MyISAM оказался всегда быстр, InnoDB всё медленнее и медленнее с ростом количества записей.

И пост немного не про это — можете использовать InnoDB, другую структуру, индексы и т.п.

[@sl4mmer]

Скорее всего ваш тест был непоказателен (особенности конфига например). Статья конечно не на эту тему — но у постороннего человека, может сложится мнения что myisam производительнее, что несовсем так.

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

[@Aleks_ja]

Уберу спорное заявление :)

[@weirdan]

В однопоточном сценарии (один клиент, цикл) myisam действительно работает быстрее. В свою очередь InnoDB может выигрывать в случае фрагментированной таблицы в многопоточном сценарии (много клиентов, например, нагруженый вебсервер).

[@vitalets]

помоему сложновато получилось.
Не проще ли записывать все PHP-данные в таблицу типа session и в триггерах просто подтягивать эту информацию?

[@Aleks_ja]

Вроде всё предельно просто…

По-поводу вашего предложения — как минимум: у вас каждый раз будет что-то куда-то писаться, а не только при изменении данных, за которыми следим и проблема по-больше — как мы из триггера узнаем кто именно залогинен на этой страничке? Как решение — вижу временную таблицу :) Про что и пост.

[@ToSHiC]

Зачем временная таблица, если есть переменные?

[@Aleks_ja]

А в MySQL можно узнать установлена ли переменная? Нам нужно что-то вроде массива, но конкатенация также подошла бы, однако если делать set @param = concat(@param,'12'); а @param раньше не была создана — будет ругаться. Но, впринципе, можно её сетить в самом начале скрипта, а потом уже конкатенировать в неё айдишники.

[@ToSHiC]

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

[@Aleks_ja]

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

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

[@Aleks_ja]

Здесь не просто про триггер, читайте внимательнее. Про салат — также читайте внимательнее. "Выяснить, можно ли динамически использовать названия колонок в триггерах — не удалось". По ссылке там про процедуры также говорится, не всё так просто. Если же вы сможете сделать через процедуру, которая вызывается триггером — то сразу же проапдэйчу пост.

[@vitalets]

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

[@Aleks_ja]

Триггер здесь через PHP формируется для удобства. Для каждой таблички их 3 создаётся. Если это делать вручную, придётся колонки перебирать и т.п.

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

Чтобы посмотреть какой код для триггера генерирует функция, можно просто распечатать в ней $triggerContent