Pull to refresh

Comments 25

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

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

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

К тому же, если уж зашел разговор — успешный инсерт в myisam не гарантирует, что ваши данные действительно сохранятся. Myisam просто помещает их в память, в расчете на то, что сервер, как будет время сохранит их на диск. Ну соответственнов в случае падения сервера приходит пушной зверек, целостность данных может быть нарушена полностью.
В однопоточном сценарии (один клиент, цикл) myisam действительно работает быстрее. В свою очередь InnoDB может выигрывать в случае фрагментированной таблицы в многопоточном сценарии (много клиентов, например, нагруженый вебсервер).
помоему сложновато получилось.
Не проще ли записывать все PHP-данные в таблицу типа session и в триггерах просто подтягивать эту информацию?
Вроде всё предельно просто…

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

Основной смысл — суметь заматчить любое изменение в бд на конкретный скрипт, пользователя и т.п. И переменные и временные таблицы — для отдельного коннекта существуют, поэтому и то и то подходит. Проапдэйчу пост немного как проверю как лучше сделать с переменными.
UFO just landed and posted this here
Здесь не просто про триггер, читайте внимательнее. Про салат — также читайте внимательнее. "Выяснить, можно ли динамически использовать названия колонок в триггерах — не удалось". По ссылке там про процедуры также говорится, не всё так просто. Если же вы сможете сделать через процедуру, которая вызывается триггером — то сразу же проапдэйчу пост.
еще вопрос:
а зачем вы создаете триггер динамически? почему бы просто не создать их статически на те таблицы, где нужно логирование?
и кстати, после выполнения скрипта триггер так и остается висеть в базе?
Триггер здесь через PHP формируется для удобства. Для каждой таблички их 3 создаётся. Если это делать вручную, придётся колонки перебирать и т.п.

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

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

Articles