powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / И снова логи
12 сообщений из 12, страница 1 из 1
И снова логи
    #38464106
Фотография Сергей Лалов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, всем привет! Столкнулся с вопросом логирования на сервере MySQL в пределах определенной базы, определенной таблицы. Отслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей? Чтобы сам текст запроса не высвечивался? А то в отчете стоит и имя пользователя, и текст запроса со значениями. Неудобно как то смотриться. Не знаю как зацепиться за конкретное поле
...
Рейтинг: 0 / 0
И снова логи
    #38464140
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Первое, что приходит в голову - триггером сравнивать и при изменении сливать изменившиеся данные в отдельную таблицу...
...
Рейтинг: 0 / 0
И снова логи
    #38464200
Фотография Сергей Лалов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akina,
Спасибо! Я в принципе в этом направлении и копал. Единственно хочу уточнить, может не в таблицу сливать, а в текстовый файлик в папку какую нить , потому что замес по количеству данных планируется очень большой.
...
Рейтинг: 0 / 0
И снова логи
    #38464203
Фотография Сергей Лалов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В основной таблице планируется 20 полей где то с начальным объемом порядка 60 тысяч строк.
И изменяться значения будут очень часто
...
Рейтинг: 0 / 0
И снова логи
    #38464348
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я у себя веду лог изменений тригером.
Количество изменений небольшое (около 100 тысячь в сутки) и всё закидывается в отдельную таблицу.

А почему ты хочешь закидывать изменения в файл? Считаешь это более быстрым? Я бы тут поспорил... Даже если бы ты писал свою программу на Delphi, и то не факт что она бы складывала в файл (или файлы) информацию быстрее чем это делает MySQL (да хотя бы за счёт той же буферищации). А если придумывать костыли с выгрузкой информации из MySQL в файлы - это будет значительно медленней. И поиск среди изменений в текстовом файле будет стократно медленней чем из таблицы в базе данных.

Мне бы хотелось услышать аргументы в пользу текстового файла с логами изменений.
...
Рейтинг: 0 / 0
И снова логи
    #38464440
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ЛаловЕдинственно хочу уточнить, может не в таблицу сливать, а в текстовый файлик в папку какую нить , потому что замес по количеству данных планируется очень большой.
Определите это "очень большой" в штуках в, скажем, сутки. Сколько будет добавлений, изменений и удалений - по отдельности...

В принципе триггер - не очень хорошее решение. Тяжелит исполнение, но главное - триггер не срабатывает на часть действий, которые вызывают изменение в данных.

Гарантированный и достаточно быстрый "лог" делается добавлением в структуру полей bValid (boolean) и dtChanged (timestamp). При этом изменение и удаление заменяются на простановку признака невалидности (при изменении - плюс добавление валидной записи), а штамп времени обновляется автоматически и служит для вторичного контроля. Если изменения часты - таблица быстро растёт, потому следует хорошо продумать операцию "чистки" от невалидных записей. Неплохие результаты даёт, например, партиционирование по полю валидности.
...
Рейтинг: 0 / 0
И снова логи
    #38464442
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, слив в текстовый файл - заведомо менее выгодное решение. Даже не заморачивайся.
...
Рейтинг: 0 / 0
И снова логи
    #38467082
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akinaтриггер не срабатывает на часть действий, которые вызывают изменение в данных.
Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?)
Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно.
...
Рейтинг: 0 / 0
И снова логи
    #38467088
Фотография Сергей Лалов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyAkinaтриггер не срабатывает на часть действий, которые вызывают изменение в данных.
Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?)
Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно.

Это вы наверное не дожали логику в подчиненных таблицах, куда устремляется каскадное удаление после того как снесет данные в главных таблицах. Так то вроде отклики на события приходят со всех таблиц, на которые слежение повешено.
...
Рейтинг: 0 / 0
И снова логи
    #38467143
deblogger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторОтслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей?


Типа при вставке и удалении "значения полей" могут не измениться. Убдейт по мануалу не обновляет совпадающие значения автоматически. Следовательно надо найти признак указывающий на совпадение тупли с отправленными данными.
...
Рейтинг: 0 / 0
И снова логи
    #38467158
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ЛаловInterSkyпропущено...

Так это только при обращении через API и при каскадных удалениях (или как они там в innoDB назвывются?)
Может кто-то этим и пользуется, но для своих проектов всегда знаешь что безопасно.

Это вы наверное не дожали логику в подчиненных таблицах, куда устремляется каскадное удаление после того как снесет данные в главных таблицах. Так то вроде отклики на события приходят со всех таблиц, на которые слежение повешено.
Раз ты уже в Москве, может по-русски напишешь? А то что-то недожали и где-то отклики устремились.
...
Рейтинг: 0 / 0
И снова логи
    #38467160
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
debloggerавторОтслеживать нужно insert, update, delete. Как нибудь можно парсить только изменения значений полей?


Типа при вставке и удалении "значения полей" могут не измениться. Убдейт по мануалу не обновляет совпадающие значения автоматически. Следовательно надо найти признак указывающий на совпадение тупли с отправленными данными.
Изменение - это отличие значения Field.old от Field.new
При вставке и удаление эти значения отличаются, и тригер запишет разницу.
Если при апдэйте пользователь поменял 22 на 22 - то это не будет записано (и по мануалу и по логике нам такое изменение не интересно), тригер покажет только те поля которые изменили значения. В результате мы не храним кучу дублирующей информации, а только реальные изменения внесённые пользователем (то что и просит автор темы).
...
Рейтинг: 0 / 0
12 сообщений из 12, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / И снова логи
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]