|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
13.11.2013, 21:03:07
|
|||
|---|---|---|---|
|
|||
И снова логи |
|||
|
#18+
Коллеги, всем привет! Столкнулся с вопросом логирования на сервере MySQL в пределах определенной базы, определенной таблицы. Отслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей? Чтобы сам текст запроса не высвечивался? А то в отчете стоит и имя пользователя, и текст запроса со значениями. Неудобно как то смотриться. Не знаю как зацепиться за конкретное поле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2013, 21:40:40
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Первое, что приходит в голову - триггером сравнивать и при изменении сливать изменившиеся данные в отдельную таблицу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2013, 22:36:30
|
|||
|---|---|---|---|
|
|||
И снова логи |
|||
|
#18+
Akina, Спасибо! Я в принципе в этом направлении и копал. Единственно хочу уточнить, может не в таблицу сливать, а в текстовый файлик в папку какую нить , потому что замес по количеству данных планируется очень большой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.11.2013, 22:38:05
|
|||
|---|---|---|---|
|
|||
И снова логи |
|||
|
#18+
В основной таблице планируется 20 полей где то с начальным объемом порядка 60 тысяч строк. И изменяться значения будут очень часто ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2013, 01:49:20
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Я у себя веду лог изменений тригером. Количество изменений небольшое (около 100 тысячь в сутки) и всё закидывается в отдельную таблицу. А почему ты хочешь закидывать изменения в файл? Считаешь это более быстрым? Я бы тут поспорил... Даже если бы ты писал свою программу на Delphi, и то не факт что она бы складывала в файл (или файлы) информацию быстрее чем это делает MySQL (да хотя бы за счёт той же буферищации). А если придумывать костыли с выгрузкой информации из MySQL в файлы - это будет значительно медленней. И поиск среди изменений в текстовом файле будет стократно медленней чем из таблицы в базе данных. Мне бы хотелось услышать аргументы в пользу текстового файла с логами изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2013, 08:34:11
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Сергей ЛаловЕдинственно хочу уточнить, может не в таблицу сливать, а в текстовый файлик в папку какую нить , потому что замес по количеству данных планируется очень большой. Определите это "очень большой" в штуках в, скажем, сутки. Сколько будет добавлений, изменений и удалений - по отдельности... В принципе триггер - не очень хорошее решение. Тяжелит исполнение, но главное - триггер не срабатывает на часть действий, которые вызывают изменение в данных. Гарантированный и достаточно быстрый "лог" делается добавлением в структуру полей bValid (boolean) и dtChanged (timestamp). При этом изменение и удаление заменяются на простановку признака невалидности (при изменении - плюс добавление валидной записи), а штамп времени обновляется автоматически и служит для вторичного контроля. Если изменения часты - таблица быстро растёт, потому следует хорошо продумать операцию "чистки" от невалидных записей. Неплохие результаты даёт, например, партиционирование по полю валидности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.11.2013, 08:35:03
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Да, слив в текстовый файл - заведомо менее выгодное решение. Даже не заморачивайся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.11.2013, 00:31:36
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Akinaтриггер не срабатывает на часть действий, которые вызывают изменение в данных. Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?) Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.11.2013, 00:53:30
|
|||
|---|---|---|---|
|
|||
И снова логи |
|||
|
#18+
InterSkyAkinaтриггер не срабатывает на часть действий, которые вызывают изменение в данных. Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?) Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно. Это вы наверное не дожали логику в подчиненных таблицах, куда устремляется каскадное удаление после того как снесет данные в главных таблицах. Так то вроде отклики на события приходят со всех таблиц, на которые слежение повешено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.11.2013, 02:59:06
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
авторОтслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей? Типа при вставке и удалении "значения полей" могут не измениться. Убдейт по мануалу не обновляет совпадающие значения автоматически. Следовательно надо найти признак указывающий на совпадение тупли с отправленными данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.11.2013, 04:15:09
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
Сергей ЛаловInterSkyпропущено... Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?) Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно. Это вы наверное не дожали логику в подчиненных таблицах, куда устремляется каскадное удаление после того как снесет данные в главных таблицах. Так то вроде отклики на события приходят со всех таблиц, на которые слежение повешено. Раз ты уже в Москве, может по-русски напишешь? А то что-то недожали и где-то отклики устремились. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.11.2013, 04:30:36
|
|||
|---|---|---|---|
И снова логи |
|||
|
#18+
debloggerавторОтслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей? Типа при вставке и удалении "значения полей" могут не измениться. Убдейт по мануалу не обновляет совпадающие значения автоматически. Следовательно надо найти признак указывающий на совпадение тупли с отправленными данными. Изменение - это отличие значения Field.old от Field.new При вставке и удаление эти значения отличаются, и тригер запишет разницу. Если при апдэйте пользователь поменял 22 на 22 - то это не будет записано (и по мануалу и по логике нам такое изменение не интересно), тригер покажет только те поля которые изменили значения. В результате мы не храним кучу дублирующей информации, а только реальные изменения внесённые пользователем (то что и просит автор темы). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=47&tablet=1&tid=1835707]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
33ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 349ms |
| 0 / 0 |
