|
|
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Всем привет! Пишу БД и возник вопрос, каким путём лучше или можно вести протокол событий. Ну что какой пользователь сделал, что изменил! В настоящий момент собираюсь сделать таблицу и в неё все данные записывать! Конечно в итоге даже за день работы табличка станет не маленькой, но для этого я планирую сделать выгрузку хотябы в тотже Access ! Тоесть если человек захочет посмотреть кто недавно чтото сделал, то он посмотрит в Журнаде, а если давнее, то в Акцесовском файле... Может не удобно, зато экономично... Но может кто то предложит что то получше, буду очент признателен! Да, и СУБД будет PostgreSQL, но на самом деле этот принцеп я собираюсь использовать и вдругих СУБД! Спасибо всем, жду Ваших сообщений! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 00:46 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Мне нравится для протоколирования изменений в таблице использовать копию этой таблицы с дополнительными полями и триггер, который на update и delete копирует старую запись из основной таблицы в таблицу-журнал, по ходу добавляя к журнальной записи дату и код автора изменения. Обычно update и delete случаются не часто, так что журнал не растёт очень быстро. А поскольку записи в журнале структурированы так же как в основной таблице, не сложно написать достаточно быстрые SQL запросы, которые детально покажут кто, когда и как изменял записи. Таким образом для каждой журналируемой таблицы имеем таблицу журнал и триггер, который этот журнал заполняет. Однако, современные СУБД, например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 04:11 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
LeximusВ настоящий момент собираюсь сделать таблицу и в неё все данные записывать! Зависит от операции: добавление объекта: кто, когда изменение объекта: кто, когда, было, стало удаление объекта: отдельный список удаленных объектов + кто, когда удалил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 10:00 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени. у оракла есть аудит, то что нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 10:34 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Чендлер mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени. у оракла есть аудит, то что нужно. Аудит больше подходит для контроля за действиями DBA, пользователи же могут делать всё что угодно в рамках своих полномочий, да и собственно изменённые данные он не отслеживает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 10:54 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
mcureenab Чендлер mcureenab например ОРАКЛ, умеют выполнять запросы по журналу транзакций, что теоретически позволяет в недалёком прошлом так же находить факты изменения БД и даже используя ретроспективные запросы сравнивать состояния БД в разные моменты времени. у оракла есть аудит, то что нужно. Аудит больше подходит для контроля за действиями DBA, пользователи же могут делать всё что угодно в рамках своих полномочий, да и собственно изменённые данные он не отслеживает. Согласен! Да и сложно будет сделать журнал операций. Имею в виду программу для просмотра ЛОГА! Чтобы не только Администратор БД мог посмотреть что кто менял, но и обычный смертный! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 10:58 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
На самом деле мне нравятся два варианта... Первый: У каждой таблицы иметь дублирующую. таблицу(Таблицу Журнал), но с некоторыми дополнительными полями. Второй: Иметь таблицу Протокола, в которой записывается тип операции(изменение, удаление, добавление и т.д.), будет Идентификатор таблицы(в какой таблице), ID записи таблицы, Поте таблицы, и что на что поменялось или удалилось! Но у обоих естькак свои достоинства так и недостатки! Например у первого варианта всё будет с одной стороны нагляднее, в плане того что чётко вся строка, но журнал операций сложно сделать по всем таблицам одновременно. А во втором варианте легко сделать журнал операций, но очень много всё занимать будет! Кстати в 1С ктонибудь знает как это сделано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 11:06 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
В 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 Средство просмотра применяет фильтры и выводит в грид результат. ЗЫ Касаемо второго варианта. А что мешает делать новую таблицу через определенный промежуток времени (журнал за год, за квартал, месяц)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2008, 13:08 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Придумал ещё один вариант, прошу оценить! Конечно этот вариант скорее всего будет больше всего занимать места, но может будет удобен! Надо создать таблицу, в которой есть по несколько полей разного типа! Ну например несколько текстовых, несколько цифровых, несколько дробных и т.д.! Вообщем максимальное количетсво полей определённого типа из разных таблиц. Таблица будет называться Protokol ! В разных таблицах, разное количество полей... Например в таблице Сотрудники, больше всего полей с текстовым типом (5 полей), соответственно в таблицу Protokol добавляем 5 текстовых полей... В таблице Прайс, больше всего полей с дробными числами (7 полей), соответственно в таблицу Protokol добавляем 7 полей с дробными числами... и так далее!!! Так же добавить признак таблицы( от куда будут добавляться данные), дата добавления(соответственно изменения)... За то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно! Кто что скажет насчёт этого варианта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 13:51 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
LeximusЗа то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно! Кто что скажет насчёт этого варианта? Неприятно то, что при изменении одного самого маленького значения придется сохранять всю запись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 15:07 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Сергей Васкецов LeximusЗа то например когда целиком будут строку менять, то все изменения можно будет просмотреть построчно! Кто что скажет насчёт этого варианта? Неприятно то, что при изменении одного самого маленького значения придется сохранять всю запись. Согласен, но при удалении всей строки лучше не придумаешь... Да и при изменении сразу нескольких полей в других ситуациях пришлосьб делать кучу строк... И на каждое поле кучу повторяющихся данных... Кто например изменил, когда, что сделал и в какой таблице! Ну это я так, для беседы защищаю этот вариант! Сам я понимаю что это громозко может выйти! Но другие варианты не лучше. Вот и хочу из них выбрать один поприличнее! И на мой взгляд, этот самый нормальный пока! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 16:43 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
ИМХО надо исходить из того, зачем вам нужна эта история, и как часто ей будут пользоваться... у меня пока не попадались случаи, когда надо было посмотреть, кто изменил какое-то поле 37 дней назад... в большенстве случаев - кто когда подключился к БД, когда создал документ, когда удалил, когда backup сделал и.т.д.... в этом случае - лучше отдельная таблица, где много полей, и можно инфу обо всех необходимых событиях разместить... другое дело, если надо постоянно обращаться к прошлым записям... тогда вообще лучше добавлять к каждой записи, поле даты и статус... записи вообще не удалять, а ставить пометку "удалена" и дату удаления. вот только надо будет почти на все операции триггеры, всё будет медленне работать, и таблицы будут большими большими :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 20:22 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
LeximusДа и при изменении сразу нескольких полей в других ситуациях пришлосьб делать кучу строк... И на каждое поле кучу повторяющихся данных... Кто например изменил, когда, что сделал и в какой таблице!Можно и 1коМногим сделать: Кто,Когда,Где-Что Но ИМХО это зависит от самой базы и характера работы с базой У нас, например, данные почти не меняются, дык сделано как говорит Кифирчик ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2008, 20:53 |
|
||
|
Ведение протокола операций!
|
|||
|---|---|---|---|
|
#18+
Универсальный логатор - две таблицы один ко многим: В первой столбцы - счетчик или иной ключ, название изменяемой таблицы, действие на изменяемой таблицей (insert, update, delete), дата и время, пользователь (название компа, название приложения, другие идентификаторы) Во второй таблице: связанное поле, название логируемого поля, значение поля (удаленного, измененного). Тригеры в логирумых таблицах. Логировать инсерты смысла не вижу честно говоря. Идентификаторы пользователя можно вынести в третью таблицу, предусмотреть автоматическое заполнение в логирующей хранимке. Названия таблиц аналогично вынести в четвертую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2008, 01:25 |
|
||
|
|

start [/forum/topic.php?fid=32&gotonew=1&tid=1544004]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
168ms |
get topic data: |
12ms |
get first new msg: |
6ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 488ms |

| 0 / 0 |
