Спустя 3 минуты, 55 секунд (16.06.2010 - 07:47) Kuzya написал(а):
Создаём триггер на "после обнвления", и внутри него используем OLD (старая запись, до обновления) или NEW (новая запись, после него.)
Вот тут можно прочитать и про OLD и про NEW
http://www.rldp.ru/mysql/mysqlpro/triggers.htm
Вот тут можно прочитать и про OLD и про NEW
http://www.rldp.ru/mysql/mysqlpro/triggers.htm
Спустя 26 минут, 30 секунд (16.06.2010 - 08:14) tomash написал(а):
А из логов вытянуть можно? MySQL триггеры еще не "фонтан" - слишком медленно работают
Спустя 3 часа, 21 минута, 30 секунд (16.06.2010 - 11:35) Kuzya написал(а):
| Цитата |
| А из логов вытянуть можно? |
Наврятли, точно не скажу
| Цитата |
| MySQL триггеры еще не "фонтан" - слишком медленно работают |
Странно. Я работаю с несколькими большими проектами, имеющими огромные БД. Множество их табилиц окружены 2-3 триггерами и работают вполне быстро.
Спустя 3 минуты, 13 секунд (16.06.2010 - 11:39) Basili4 написал(а):
Я тоже не заметил проблем с быстродействием. очень хорошая весчь эти тригеры.
Спустя 25 минут, 1 секунда (16.06.2010 - 12:04) tomash написал(а):
Kuzya
Я не пользуюсь! При онлайне в 4-5 тыс. это ппц. Слежу за целостностью из скрипта.
Я не пользуюсь! При онлайне в 4-5 тыс. это ппц. Слежу за целостностью из скрипта.
Спустя 4 минуты, 18 секунд (16.06.2010 - 12:08) waldicom написал(а):
| Цитата (Basili4 @ 16.06.2010 - 10:39) |
| Я тоже не заметил проблем с быстродействием. очень хорошая весчь эти тригеры. |
А чем они так хороши?
Спустя 3 минуты, 31 секунда (16.06.2010 - 12:11) Kuzya написал(а):
А чем они так хороши?
Можно например логировать все изменения важных полей в таблицах, чтоб в случае катастрофы сделать быстрый откат на час назад, или на минуту
Очень удобно. Спустя 6 минут, 40 секунд (16.06.2010 - 12:18) SlavaFr написал(а):
Тригеры я считаю опасной штукой.
Причина тому то, что Логика которая в программном коде лежать должна переносится БД, где собственно не какой логики кроме референциального интегритета быть не должно.
Тригер может использовать Администратор БД, чтобы решать спицифические вопросы которые связаны с прямыми статистиками или другими чисто для Б.Д. потребными обслуживающими работами.
Работа с тригером через программы вызовет первые проблемы сразу при наличии новых людей которые должны работать с програмным кодом, так как они должны не только структуру Таблиц изучать, но и искать какуюто дополнительную запрятаную в Б.Д. Логику, там где ее собственно быть не должно.
я не берусь судить о перформантности тригера. возможно он даже быстрей чем 2 или 3 простых запросов. Я знаю одно, перформантность можно относительно не дорого купить, а вот непонимание программистов и затуманивание проэктов обойдется немыслемо дорого.
Причина тому то, что Логика которая в программном коде лежать должна переносится БД, где собственно не какой логики кроме референциального интегритета быть не должно.
Тригер может использовать Администратор БД, чтобы решать спицифические вопросы которые связаны с прямыми статистиками или другими чисто для Б.Д. потребными обслуживающими работами.
Работа с тригером через программы вызовет первые проблемы сразу при наличии новых людей которые должны работать с програмным кодом, так как они должны не только структуру Таблиц изучать, но и искать какуюто дополнительную запрятаную в Б.Д. Логику, там где ее собственно быть не должно.
я не берусь судить о перформантности тригера. возможно он даже быстрей чем 2 или 3 простых запросов. Я знаю одно, перформантность можно относительно не дорого купить, а вот непонимание программистов и затуманивание проэктов обойдется немыслемо дорого.
Спустя 1 минута, 48 секунд (16.06.2010 - 12:20) waldicom написал(а):
| Цитата (Kuzya @ 16.06.2010 - 11:11) |
| Можно например логировать все изменения важных полей в таблицах, чтоб в случае катастрофы сделать быстрый откат на час назад, или на минуту smile.gif Очень удобно. |
Нифига се! А пользоваться стандартными средствами?
И SlavaFr очень хорошо написал про логику в БД, которой там не должно быть (по моему имхастому имху).
Спустя 18 минут, 36 секунд (16.06.2010 - 12:38) Kuzya написал(а):
| Цитата |
| Нифига се! А пользоваться стандартными средствами? |
Какими например? Делать бэкап таблицы кроном каждую секунду? Триггер может в обычную таблицу складывать например только какое поле изменилось, с какого значение на какое и всё.
Это кстати лишь один пример их использования, возможно есть ещё много вариантов.
Спустя 3 минуты, 40 секунд (16.06.2010 - 12:42) tomash написал(а):
Kuzya
для такого случая придумали бинарный лог
для такого случая придумали бинарный лог
Спустя 3 минуты, 31 секунда (16.06.2010 - 12:46) Basili4 написал(а):
У меня например есть несколько таблиц для отслеживания состояний обектов и мне очень удобно что внутири базы выполняется вся черовая работа. Я просто исполняю запросы на выбор данных из таблиц не задумываясь о том как эти данные туда попали.
Спустя 1 час, 32 минуты, 25 секунд (16.06.2010 - 14:18) SlavaFr написал(а):
Мы работаем с Б.Д где на данный момент находится около 750 таблиц с данными которые вообще не когда не удаляются и изменения мозжно в лубой момент проследить. Да, вемсто delete мы садим столб deleted='1' a вмсесто update
создаем новую строчку с изменениями, где увеличиваем версионный номмер, вносим ид юзера, который изменил, а также вносим дату изменения.
Да, запросы более сложны, так как для актуальной версии нужно дополнительно махимальную версию указывать и конечно ключи теперь состоят минимум из двух столбов (ключ и версионный номмер), но все это себя оправдывает, так как структура понятна и нет не каких скрытых действий. На сколько ситуация позволяет прячeм такие операции в приватные методы или функции и таким образом вся черная работа остается спрятанна, но в тоже время легко доступна.
создаем новую строчку с изменениями, где увеличиваем версионный номмер, вносим ид юзера, который изменил, а также вносим дату изменения.
Да, запросы более сложны, так как для актуальной версии нужно дополнительно махимальную версию указывать и конечно ключи теперь состоят минимум из двух столбов (ключ и версионный номмер), но все это себя оправдывает, так как структура понятна и нет не каких скрытых действий. На сколько ситуация позволяет прячeм такие операции в приватные методы или функции и таким образом вся черная работа остается спрятанна, но в тоже время легко доступна.
_____________