|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Firebird 3. Давно на просторах интернета встречал примеры, как можно довольно просто (но только с версии 2.1 или 2.5) логировать изменения полей конкретной записи централизовано. Т.е. сохранять в лог старое и новое значение. Да, можно записывать в таблицу изменения, обозначая каждое поле, но это неудобно + рутина, т.к. таблиц много, полей много, к тому же если нужно изменить/добавить/удалить поле... Просто хочется, не заботясь о названии таблицы и полей, скопипастить одинаковый код для триггеров нужных таблиц. Как получать название таблицы в триггере уже есть пример 6980844 Я помню, что данные записывались в текстовом виде в BLOB типа: Код: plaintext 1. 2. 3.
Может у кого есть примеры, идеи? Может у FB 3 уже есть возможность создать один единый триггер, который будет реагировать на все таблицы? Иначе если менять что-то по всем триггерам, то рутина много времени отнимает. А если нужно будет создать скрипты для обновления другой базы... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 17:38 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
30.11.2017 17:38, X11 пишет: > Я помню, что данные записывались в текстовом виде в BLOB типа: уху еть! дайте два! (С) зы: где ты это откопал? закопай обратно нах Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 17:43 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11, напиши PSQL пакет утилит для автоматического формирования скрипта создания INSERT, UPDATE, DELETE триггеров и всё. И потом тупо пользуйся им ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 17:45 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11Как получать название таблицы в триггере уже есть пример 6980844 1. создать один триггер на таблицы данных нельзя, никак. Для изменений DDL можно, но это другая тема. 2. с таким триггером как в "примере", вставка и обновление будет тормозить. 3. имя поля таким же способом получить будет можно, но бессмысленно, т.к. никак не привязать к new и old, даже через ES (там не будет этого контекста). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 18:52 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
kdv2. с таким триггером как в "примере", вставка и обновление будет тормозить. Особенно, если ещё и в параллельную БД записывать? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 19:25 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
kdvникак не привязать к new и old В принципе, это и не надо. Старые данные будут видны в предыдущей записи. Т.е. пишет только текущие. Таким образом, можно в хранимой процедуре, если передать в неё имя таблицы, сделать как бы цикл по полям? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 19:55 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11, 'Таблиц много, полей много"... получаем сверхмедленную (на изменения) базу, в основном загруженную логами... тут очень важно логировать изменение логов, чтобы никто не подчистил... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 21:09 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Я имел ввиду, что не в одной транзакции много таблиц при добавлении. Много таблиц - это значит, что справочники разные, др. служебные таблицы. Но добавление происходит в одну таблицу, а не сразу в 10. Много таблиц + много полей - это много рутины при попытке подправить структуру, триггеры, процедуры. А было бы централизовано, было бы замечательно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 21:15 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11, в конце-концов, в IBE есть шаблоны таких триггеров. И есть тулза LogManager. Ну и, есть IBReplicator. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 21:18 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11> Но добавление происходит в одну таблицу, а не сразу в 10. Блажен, кто верует. Триггеры и ХП вполне себе несколько таблиц меняют. > Много таблиц + много полей - это много рутины при > попытке подправить структуру, триггеры, процедуры. > А было бы централизовано, было бы замечательно. Конечно. Это ж работать надо. Гораздо приятнее было бы, чтобы оно "само". :) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 21:24 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам... Конечно. Это ж... Некоторые просят протоколировать не только изменения, но и чтения. :) ... Самое прикольное, что тот, кто выкатил требование "все должно протоколироваться", при эксплуатации обычно оказывается вообще не при делах. Да и что потом с этими логами делать - непонятно. А если продукт "коробочный", то протокол уровня "кто поменял данные в табличке" смысла не имеет. Клиента обычно фик убедишь насчет необходимости хотя бы минимального администрирования, а тут - логи анализировать, "кто удалил накладную". Тут и в структуре базы разбираться нужно, и в бизнес-процессах. Вот протоколирование уровня "документ" - другое дело, даже порой полезно, но это уже совсем другой уровень технической реализации... ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:08 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
чччД, согласен. Можно добавить галочку в настройках для включения/отключения протоколирования. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:12 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, да, оно само - так и должно быть. Что плохого в автоматизации? Ради этого всё и делается. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:14 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11чччД, согласен. Можно добавить галочку в настройках для включения/отключения протоколирования. Объясни заказчику, что реализовать можешь. Но полноценная реализация (система фиксации изменений, система анализа логов, обучение персонала, объясни насчет разницы между физической и логической структурами...) потребует отдельного времени на реализацию, затем затруднит реализацию основной бизнес-логики, в разы увеличит потребность в дорогой быстрой (SSD же ж) дисковой памяти и гарантированно сделает систему медленной при работе под нагрузкой. Пусть принимает решение, что ему в первую очередь нужно - реализовать тотальную слежку или возможность формировать отчеты. Бронированный "Черный ящик" весом в 5 тонн vs всепогодный гарантированный лазерный уничтожитель человеков для МиГ-66. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:22 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Это всё отмазки. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:23 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11Это всё отмазки. Да. Бессмысленную работу следует игнорировать, из-за всех сил. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:24 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Ну ладно. Может, будут идеи? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:26 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
X11Ну ладно. Может, будут идеи? Напиши программку, генерирующую необходимую обвязку в базе и тексты триггеров для каждой таблички. Посмотри, как в IBExpert сделано: ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:38 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
чччД> Некоторые просят протоколировать не только изменения, но и чтения. :) Подтверждаю. Буквально пару дней назад мне звонили, спрашивали - "а можно узнать, кто ДД.ММ.ГГ распечатал такой-то документ?" При том что, фактически, распечатать можно и мимо ПО вообще. > Самое прикольное, что тот, кто выкатил требование > "все должно протоколироваться", при эксплуатации > обычно оказывается вообще не при делах. Протоколирование тут ничем не выделяется, так почти со всеми требованиями, ибо их выкатывают чаще всего не те, кому придётся со всем этим работать, а их начальство (и это ещё хорошо, если непосредственное, а не через-через). А внизу люди, как правило, куда более адекватные - те хоть свою работу (рутину) ежедневную более-менее знают, звёздных планов не строят. > Да и что потом с этими логами делать - непонятно. Ты уж совсем-то не перегинай. Логи нужны, чтобы когда наступит "час Ха" найти виновного. И если логов не будет, виновного могут не искать, а "назначить" (может, даже не одного). В т.ч. могут выбрать кого-нибудь из ИТ. Правда, назначить могут даже при наличии логов, было бы желание. :) > протокол уровня "кто поменял данные в табличке" смысла не имеет. > Вот протоколирование уровня "документ" - другое дело, даже порой > полезно, но это уже совсем другой уровень технической реализации... А это одно и то же, юзеры/клиенты на таком уровне рассуждать не могут (тупо квалификации не хватает). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.11.2017, 22:41 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, кстати, я еще IMHO добавлю, что логи надо из базы выгружать. Но так, чтобы можно было потом "найти негодяя". Просто с течением времени таблица логов станет охрененного размера, а бэкапить/ресторить все это добро все дольше и дольше. p.s. Типа, как КЛАДР в 1С. Грузится в базу, опционально, по мере добавления клиента из какого-то региона. Но клиент что-то купит один раз, а этот кусок КЛАДРа будет торчать в базе вечно. И там же запись не об одном адресе, а целиком по региону. Понятно что это не лог, но тоже полу-бесполезная в базе информация. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 00:38 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
kdv> кстати, я еще IMHO добавлю, что логи надо из базы выгружать. От размеров зависит и от того, что ты называешь "выгружать". Я не припомню случаев, когда нужно было более чем два года назад (2 календарных - текущий неоконченный и предыдущий). Соответственно, 01.01 - можно тупо очищать старые логи, они итак в старых бэкапах сохраняются. Касательно КЛАДР и пр. внешних источников - подгружать по ходу можно только если ПО - *клиентское* - работает с ними напрямую. Если нет - получаются всякие кривости. Да и не самая это большая проблема, тот же КЛАДР в БД не самый большой кусок. Ну если жмёт - ну можно вынести в отдельный kladr.fdb и обращаться через on external, но это сомнительная экономия, ИМХО. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 02:05 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамчччД> Некоторые просят протоколировать не только изменения, но и чтения. :) Подтверждаю. Буквально пару дней назад мне звонили, спрашивали - "а можно узнать, кто ДД.ММ.ГГ распечатал такой-то документ?" При том что, фактически, распечатать можно и мимо ПО вообще. А у меня сделано протоколирование распечатки документов. Оказалось очень удобно. Запись в лог производится в момент отправки на печать из FastReport. В лог пишется: - дата-время - user - ip - id печатной формы - id документа Причем это оказалось настолько удобно что коичество распечаток по документу выводится прямо в журнале документов, а зайя в свойства документа видно и все остальные поля лога. К примеру если попытаться распечатать второй раз документ в виде "заказа на отгрузку" (для склада) - то выводится предупреждение что его уже печатали. Так же по бух. документам - видно печатали его или еще нет. Места занимает немного, торможений тоже не вызывает. Даже не стал делать опциональное отколючение логирования, логируется всегда. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 03:50 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
kdvГаджимурадов Рустам, кстати, я еще IMHO добавлю, что логи надо из базы выгружать. Но так, чтобы можно было потом "найти негодяя". Просто с течением времени таблица логов станет охрененного размера, а бэкапить/ресторить все это добро все дольше и дольше. У меня так и сделано :) Логи пишутся в рабочую базу, но есть механизм периодической выгрузки логов в специальную базу логов. В рабочей оставляю записи примерно за последний год, остальное выгружаю в архивную. В интерфейсе поиска по логам смотим по рабочей, при желании прямо оттуда же можно посмотреть и по архивной базе - программа сама коннектится к архивной. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 03:53 |
|
Логирование изменений записи
|
|||
---|---|---|---|
#18+
Очень полезным иногда был бы лог изменений в строках документов, и я даже его делал но потом отключил т.к. раздувает базу очень быстро, и лог получается больше самих данных, а в размере базы 90% составляют эти данные. Т.е. база раздуется в разы. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.12.2017, 03:55 |
|
|
start [/forum/topic.php?fid=40&fpage=38&tid=1561312]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
173ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 267ms |
0 / 0 |