powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ведение протокола операций!
14 сообщений из 14, страница 1 из 1
Ведение протокола операций!
    #35131442
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем привет!
Пишу БД и возник вопрос, каким путём лучше или можно вести протокол событий. Ну что какой пользователь сделал, что изменил!
В настоящий момент собираюсь сделать таблицу и в неё все данные записывать!
Конечно в итоге даже за день работы табличка станет не маленькой, но для этого я планирую сделать выгрузку хотябы в тотже Access ! Тоесть если человек захочет посмотреть кто недавно чтото сделал, то он посмотрит в Журнаде, а если давнее, то в Акцесовском файле... Может не удобно, зато экономично...
Но может кто то предложит что то получше, буду очент признателен!
Да, и СУБД будет PostgreSQL, но на самом деле этот принцеп я собираюсь использовать и вдругих СУБД!

Спасибо всем, жду Ваших сообщений!
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35131518
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мне нравится для протоколирования изменений в таблице использовать копию этой таблицы с дополнительными полями и триггер, который на update и delete копирует старую запись из основной таблицы в таблицу-журнал, по ходу добавляя к журнальной записи дату и код автора изменения.
Обычно update и delete случаются не часто, так что журнал не растёт очень быстро. А поскольку записи в журнале структурированы так же как в основной таблице, не сложно написать достаточно быстрые SQL запросы, которые детально покажут кто, когда и как изменял записи.

Таким образом для каждой журналируемой таблицы имеем таблицу журнал и триггер, который этот журнал заполняет.

Однако, современные СУБД, например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени.
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35131784
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeximusВ настоящий момент собираюсь сделать таблицу и в неё все данные записывать!

Зависит от операции:
добавление объекта: кто, когда
изменение объекта: кто, когда, было, стало
удаление объекта: отдельный список удаленных объектов + кто, когда удалил
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35131902
Чендлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени.
у оракла есть аудит, то что нужно.
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35131976
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чендлер mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени.
у оракла есть аудит, то что нужно.

Аудит больше подходит для контроля за действиями DBA, пользователи же могут делать всё что угодно в рамках своих полномочий, да и собственно изменённые данные он не отслеживает.
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35131991
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mcureenab Чендлер mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени.
у оракла есть аудит, то что нужно.

Аудит больше подходит для контроля за действиями DBA, пользователи же могут делать всё что угодно в рамках своих полномочий, да и собственно изменённые данные он не отслеживает.

Согласен! Да и сложно будет сделать журнал операций. Имею в виду программу для просмотра ЛОГА! Чтобы не только Администратор БД мог посмотреть что кто менял, но и обычный смертный!
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35132024
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На самом деле мне нравятся два варианта...

Первый: У каждой таблицы иметь дублирующую. таблицу(Таблицу Журнал), но с некоторыми дополнительными полями.
Второй: Иметь таблицу Протокола, в которой записывается тип операции(изменение, удаление, добавление и т.д.), будет Идентификатор таблицы(в какой таблице), ID записи таблицы, Поте таблицы, и что на что поменялось или удалилось!


Но у обоих естькак свои достоинства так и недостатки!

Например у первого варианта всё будет с одной стороны нагляднее, в плане того что чётко вся строка, но журнал операций сложно сделать по всем таблицам одновременно. А во втором варианте легко сделать журнал операций, но очень много всё занимать будет!

Кстати в 1С ктонибудь знает как это сделано?
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35132516
sqllex
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В 1С 7 журнал ведется в текстовом файле с заданной структурой.
20041125;10:09:59;Пользователь;E;Sys;OpenSession;0;Компьютер HOMER(m);;
20041125;10:10:05;Пользователь;E;Docs;DocOpen;3;;O/462/46009;РасходнаяНакладная 00009263 24.11.2004 15:11:15
20041125;10:10:08;Пользователь;E;Docs;DocWrite;2;;O/462/46009;РасходнаяНакладная 00009263 24.11.2004 15:11:15

Средство просмотра применяет фильтры и выводит в грид результат.

ЗЫ
Касаемо второго варианта. А что мешает делать новую таблицу через определенный промежуток времени (журнал за год, за квартал, месяц)?
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35155302
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Придумал ещё один вариант, прошу оценить!
Конечно этот вариант скорее всего будет больше всего занимать места, но может будет удобен!

Надо создать таблицу, в которой есть по несколько полей разного типа! Ну например несколько текстовых, несколько цифровых, несколько дробных и т.д.! Вообщем максимальное количетсво полей определённого типа из разных таблиц.
Таблица будет называться Protokol !
В разных таблицах, разное количество полей...
Например в таблице Сотрудники, больше всего полей с текстовым типом (5 полей), соответственно в таблицу Protokol добавляем 5 текстовых полей... В таблице Прайс, больше всего полей с дробными числами (7 полей), соответственно в таблицу Protokol добавляем 7 полей с дробными числами... и так далее!!!
Так же добавить признак таблицы( от куда будут добавляться данные), дата добавления(соответственно изменения)...
За то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно!

Кто что скажет насчёт этого варианта?
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35155598
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeximusЗа то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно!
Кто что скажет насчёт этого варианта?
Неприятно то, что при изменении одного самого маленького значения придется сохранять всю запись.
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35155968
Leximus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Васкецов LeximusЗа то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно!
Кто что скажет насчёт этого варианта?
Неприятно то, что при изменении одного самого маленького значения придется сохранять всю запись.

Согласен, но при удалении всей строки лучше не придумаешь... Да и при изменении сразу нескольких полей в других ситуациях пришлосьб делать кучу строк... И на каждое поле кучу повторяющихся данных... Кто например изменил, когда, что сделал и в какой таблице!

Ну это я так, для беседы защищаю этот вариант! Сам я понимаю что это громозко может выйти! Но другие варианты не лучше. Вот и хочу из них выбрать один поприличнее! И на мой взгляд, этот самый нормальный пока!
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35156490
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИМХО надо исходить из того, зачем вам нужна эта история, и как часто ей будут пользоваться...
у меня пока не попадались случаи, когда надо было посмотреть, кто изменил какое-то поле 37 дней назад...
в большенстве случаев - кто когда подключился к БД, когда создал документ, когда удалил, когда backup сделал и.т.д.... в этом случае - лучше отдельная таблица, где много полей, и можно инфу обо всех необходимых событиях разместить...

другое дело, если надо постоянно обращаться к прошлым записям...
тогда вообще лучше добавлять к каждой записи, поле даты и статус... записи вообще не удалять, а ставить пометку "удалена" и дату удаления.
вот только надо будет почти на все операции триггеры, всё будет медленне работать, и таблицы будут большими большими :)
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35156526
atv_13
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
LeximusДа и при изменении сразу нескольких полей в других ситуациях пришлосьб делать кучу строк... И на каждое поле кучу повторяющихся данных... Кто например изменил, когда, что сделал и в какой таблице!Можно и 1коМногим сделать: Кто,Когда,Где-Что
Но ИМХО это зависит от самой базы и характера работы с базой
У нас, например, данные почти не меняются, дык сделано как говорит Кифирчик
...
Рейтинг: 0 / 0
Ведение протокола операций!
    #35156793
Фотография Ёжик`
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Универсальный логатор - две таблицы один ко многим:
В первой столбцы - счетчик или иной ключ, название изменяемой таблицы, действие на изменяемой таблицей (insert, update, delete), дата и время, пользователь (название компа, название приложения, другие идентификаторы)
Во второй таблице: связанное поле, название логируемого поля, значение поля (удаленного, измененного).

Тригеры в логирумых таблицах.

Логировать инсерты смысла не вижу честно говоря.

Идентификаторы пользователя можно вынести в третью таблицу, предусмотреть автоматическое заполнение в логирующей хранимке.
Названия таблиц аналогично вынести в четвертую таблицу.
...
Рейтинг: 0 / 0
14 сообщений из 14, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Ведение протокола операций!
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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