Комментарии 25
А как быть, если на таблице уже весит триггер?
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
Вижу потенциальную проблему — на слейвах порядок выполнения запросов может отличаться
Вот, кстати, о том же в умных блогах пишут: www.mysqlperformanceblog.com/2008/09/29/why-audit-logging-with-triggers-in-mysql-is-bad-for-replication/
Вот, кстати, о том же в умных блогах пишут: www.mysqlperformanceblog.com/2008/09/29/why-audit-logging-with-triggers-in-mysql-is-bad-for-replication/
* бравзер?
>Выбираем MyISAM т.к. будет много инсертов.
Неуловил логики, почему не InnoDb?
Неуловил логики, почему не InnoDb?
Да вот да. Майисам ведь на чтение хорош.
InnoDB ведь пересчитывает индексы всё время при инсертах? По крайней мере в подсознании моём такая картина. И засекал время когда-то на инсертах.
Myisam при инсерте/апдейте ставит лок на всю таблицу, из-за чего при большом количестве запросов, база встает колом (т.к единовременно может проходить только один). InnoDb лочит только ту строку (строки) с которыми мы производим операции. Пересчитываю индексы оба движка, но там они по разному устроены. Объективно — иннодб, за счет механизма построчной блокировки, превосходит myisam на операция insert/update/delete
Я не большой специалист по разным движкам баз данных. Я просто сделал цикл локально который вставляет огромное количество записей — MyISAM оказался всегда быстр, InnoDB всё медленнее и медленнее с ростом количества записей.
И пост немного не про это — можете использовать InnoDB, другую структуру, индексы и т.п.
И пост немного не про это — можете использовать InnoDB, другую структуру, индексы и т.п.
Скорее всего ваш тест был непоказателен (особенности конфига например). Статья конечно не на эту тему — но у постороннего человека, может сложится мнения что myisam производительнее, что несовсем так.
К тому же, если уж зашел разговор — успешный инсерт в myisam не гарантирует, что ваши данные действительно сохранятся. Myisam просто помещает их в память, в расчете на то, что сервер, как будет время сохранит их на диск. Ну соответственнов в случае падения сервера приходит пушной зверек, целостность данных может быть нарушена полностью.
К тому же, если уж зашел разговор — успешный инсерт в myisam не гарантирует, что ваши данные действительно сохранятся. Myisam просто помещает их в память, в расчете на то, что сервер, как будет время сохранит их на диск. Ну соответственнов в случае падения сервера приходит пушной зверек, целостность данных может быть нарушена полностью.
В однопоточном сценарии (один клиент, цикл) myisam действительно работает быстрее. В свою очередь InnoDB может выигрывать в случае фрагментированной таблицы в многопоточном сценарии (много клиентов, например, нагруженый вебсервер).
помоему сложновато получилось.
Не проще ли записывать все PHP-данные в таблицу типа session и в триггерах просто подтягивать эту информацию?
Не проще ли записывать все PHP-данные в таблицу типа session и в триггерах просто подтягивать эту информацию?
Вроде всё предельно просто…
По-поводу вашего предложения — как минимум: у вас каждый раз будет что-то куда-то писаться, а не только при изменении данных, за которыми следим и проблема по-больше — как мы из триггера узнаем кто именно залогинен на этой страничке? Как решение — вижу временную таблицу :) Про что и пост.
По-поводу вашего предложения — как минимум: у вас каждый раз будет что-то куда-то писаться, а не только при изменении данных, за которыми следим и проблема по-больше — как мы из триггера узнаем кто именно залогинен на этой страничке? Как решение — вижу временную таблицу :) Про что и пост.
Зачем временная таблица, если есть переменные?
А в MySQL можно узнать установлена ли переменная? Нам нужно что-то вроде массива, но конкатенация также подошла бы, однако если делать set @param = concat(@param,'12'); а @param раньше не была создана — будет ругаться. Но, впринципе, можно её сетить в самом начале скрипта, а потом уже конкатенировать в неё айдишники.
Зачем вообще хранить временную таблицу со списком изменений в этой сессии, если можно сразу все данные типа имени пользователя и т.д. положить в переменные, и в триггере их сразу использовать?
Сразу ложить нельзя, т.к. запросы к бд могут идти раньше чем пользователь залогинится, до старта сессии и т.п. Каких-то переменных не быть в сессии и т.п. Потом — можно какие-то сложные действия производить только если было изменение. Но это уже дело конкретной реализации. Нравится так — пожалуйста.
Основной смысл — суметь заматчить любое изменение в бд на конкретный скрипт, пользователя и т.п. И переменные и временные таблицы — для отдельного коннекта существуют, поэтому и то и то подходит. Проапдэйчу пост немного как проверю как лучше сделать с переменными.
Основной смысл — суметь заматчить любое изменение в бд на конкретный скрипт, пользователя и т.п. И переменные и временные таблицы — для отдельного коннекта существуют, поэтому и то и то подходит. Проапдэйчу пост немного как проверю как лучше сделать с переменными.
НЛО прилетело и опубликовало эту надпись здесь
Здесь не просто про триггер, читайте внимательнее. Про салат — также читайте внимательнее. "Выяснить, можно ли динамически использовать названия колонок в триггерах — не удалось". По ссылке там про процедуры также говорится, не всё так просто. Если же вы сможете сделать через процедуру, которая вызывается триггером — то сразу же проапдэйчу пост.
еще вопрос:
а зачем вы создаете триггер динамически? почему бы просто не создать их статически на те таблицы, где нужно логирование?
и кстати, после выполнения скрипта триггер так и остается висеть в базе?
а зачем вы создаете триггер динамически? почему бы просто не создать их статически на те таблицы, где нужно логирование?
и кстати, после выполнения скрипта триггер так и остается висеть в базе?
Триггер здесь через PHP формируется для удобства. Для каждой таблички их 3 создаётся. Если это делать вручную, придётся колонки перебирать и т.п.
Вызывать функцию createWatchTrigger для определённой таблички нужно только раз (типа проинсталить). Потом этот триггер делает своё дело. Если хочется изменить что-то в триггере — можно поменять что-то в функции, и снова её вызвать. Она дропнет предыдущие триггеры и пересоздаст новые для этой таблички.
Чтобы посмотреть какой код для триггера генерирует функция, можно просто распечатать в ней $triggerContent
Вызывать функцию createWatchTrigger для определённой таблички нужно только раз (типа проинсталить). Потом этот триггер делает своё дело. Если хочется изменить что-то в триггере — можно поменять что-то в функции, и снова её вызвать. Она дропнет предыдущие триггеры и пересоздаст новые для этой таблички.
Чтобы посмотреть какой код для триггера генерирует функция, можно просто распечатать в ней $triggerContent
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Слежение за изменениями данных в MySQL при помощи PHP