Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Протоколирование изменений в БД / 25 сообщений из 69, страница 1 из 3
19.08.2005, 15:02
    #33225528
AlexG
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
Я хочу организовать следующее: при изменении какого-либо поля в какой-либо таблице в клиенте вызывается хранимая процедура, в которую передаются через параметры сведения о имени таблицы, над которой работают, название поля, предыдущее значение, которое передается двумя параметрами: тип и двоичное поле (для возможности хранить данные разных типов), ну и джругую полезную информацию.
Целесообразен ли такой механизм или есть более функциональные методы?
...
Рейтинг: 0 / 0
19.08.2005, 15:08
    #33225554
YBW
YBW
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
AlexG или есть более функциональные методы?

или есть -


научитесь излагать свои мысли в терминах и определениях предметной области, которой посвящаете свои изыскания...
...
Рейтинг: 0 / 0
19.08.2005, 15:22
    #33225597
AlexG
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
YBWили есть
Что есть-то?
...
Рейтинг: 0 / 0
19.08.2005, 16:38
    #33225819
tygra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
авторЧто есть-то?
Есть более функциональные :))

Например на каждую таблицу, которую нужно мониторить, создать копию - но в отдельной базе например, или в этой же, но со спец. именем, чтобы случайно не грохнуть. Потом повесить триггеры, которые и будут отписывать все действия.
Ну еще одну таблицу на все, в которой будет писаться, кто и что делал и ссылка на нее из таблицы-дубля, чтобы в каждой не плодить поля "юзер, дата, действие и т.д."

Эх, надо сделать отдельным модулем да и выложить мой продукт по мониторингу изменений. Вдруг кому пригодится.

В общем, время найду - сделаю и сайтец забабахаю.

-- Tygra's --
...
Рейтинг: 0 / 0
19.08.2005, 16:47
    #33225843
Andres 1
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
+1 вариант: все удаления и изменения заменить добавлением новых записей + 1 поле типа дата-время в каждую таблицу, описывающее момент учетного времени, до которого запись действительна. Проблемы будут с DRI, придется делать триггерами.
...
Рейтинг: 0 / 0
19.08.2005, 16:51
    #33225856
Протоколирование изменений в БД
Andres 1+1 вариант: все удаления и изменения заменить добавлением новых записей + 1 поле типа дата-время в каждую таблицу, описывающее момент учетного времени, до которого запись действительна. Проблемы будут с DRI, придется делать триггерами.
Эт кажись, называется "хронологические данные" (temporal data). В SQL возникнет туева хуча с трудом разгребаемых траблов.
...
Рейтинг: 0 / 0
19.08.2005, 16:57
    #33225873
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
> В SQL возникнет туева хуча с трудом разгребаемых траблов.

Например?
...
Рейтинг: 0 / 0
19.08.2005, 16:58
    #33225876
AlexG
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
дураг с инецеативой Andres 1+1 вариант: все удаления и изменения заменить добавлением новых записей + 1 поле типа дата-время в каждую таблицу, описывающее момент учетного времени, до которого запись действительна. Проблемы будут с DRI, придется делать триггерами.
Эт кажись, называется "хронологические данные" (temporal data). В SQL возникнет туева хуча с трудом разгребаемых траблов.

А в чем сие траблы заключатся?
...
Рейтинг: 0 / 0
19.08.2005, 16:58
    #33225877
Andres 1
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
дураг с инецеативой
Эт кажись, называется "хронологические данные" (temporal data). В SQL возникнет туева хуча с трудом разгребаемых траблов.
Да. Что-то будет проще (например, выбрать данные "всё как было 13 числа" или "как часто Боря менял паспорта и фамилии"), что-то станет сложнее (почти всё остальное:)
...
Рейтинг: 0 / 0
19.08.2005, 17:05
    #33225890
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
> что-то станет сложнее (почти всё остальное:)

Что "все остальное"? Примеры - в студию.
...
Рейтинг: 0 / 0
19.08.2005, 17:11
    #33225908
Протоколирование изменений в БД
2 guest_20040621
У Вас есть обратные примеры?
http://www.dbpd.com/vault/9810snod.html
...
Рейтинг: 0 / 0
19.08.2005, 17:36
    #33225993
guest_20040621
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
> http://www.dbpd.com/vault/9810snod.html

Ну и где траблы?
...
Рейтинг: 0 / 0
19.08.2005, 21:11
    #33226240
vybegallo
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
В Informix для этого есть подсистема аудита. То, что вы предлагаете, возможно и будет работать, но ресурсов сожрет немало.
...
Рейтинг: 0 / 0
19.08.2005, 23:35
    #33226292
Laox
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
AlexG ну и джругую полезную информацию
И кому эта информация будет интересна? А самое главное чем?
Логировать кто последний залез в мою чашку с ногами и плюнул в нее? А толку?
...
Рейтинг: 0 / 0
21.08.2005, 12:08
    #33226856
AlexG
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
Laox AlexG ну и джругую полезную информацию
И кому эта информация будет интересна? А самое главное чем?
Логировать кто последний залез в мою чашку с ногами и плюнул в нее? А толку?
Для банка нужно, видимо...
...
Рейтинг: 0 / 0
21.08.2005, 19:45
    #33226964
PVP
PVP
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
На триггерах не выйдет. При удалении записи они не знают имя пользователя, который выполняет действие. В записях в этот момент код старого пользователя.

В БАС сделали в рабочих таблицах поле DateUser, KodUser, в которые заносятся данные о последних корректировках. Этих данных почти достаточно для выяснения всех спорных систуаций. Но так же нет сведений об удалении.

Обходимся путем сравнения с BackUp. Он все равно делается автоматически. Без таких копий все равно работать не прилично. Если уже возникает острая необходимость найти виноватого, то скорее всего шкода такая, что потребуется поднять архивы. Из них видно - что было и что стало. А кто - выясняется в рабочем порядке.

А еще каждая хранимая процедура, вызываемая из клиентской машины, имеет параметр KodUser. Если важно то, что она делает, то может занести в журнал работы. На практике тотальная слежка сделана только в одном случае: на рабочем месте кассира по приему платежей от населения, что бы можно было обойтись без кассового аппарата.
...
Рейтинг: 0 / 0
22.08.2005, 10:33
    #33227267
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
PVPНа триггерах не выйдет. При удалении записи они не знают имя пользователя, который выполняет действие. В записях в этот момент код старого пользователя.кхмм. не подскажете эту чудо-субд, в которой сыршенно невозможно выяснить текущего пользователя? (не важно, раздельна у вас идентификация в субд и в клиенте, или нет)
...
Рейтинг: 0 / 0
22.08.2005, 13:39
    #33227862
Laox
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
Если валить в одно место логи на редактирование/удаление с разных таблиц, то это будет помойка, в которой черт ногу сломит. Ведь если появилась мысль о логгировании изменений, значит это кому то нужно. А следовательно на эту таблицу с логами надо навершивать интерфейсы для просмотра, всякие фильтры и и отчеты, причем такие, чтобы пользователи понимали об чем речь, собственно говоря.
На мой взгляд универсализация в этом месте ни к чему хорошему не приведет. Для каждой таблицы нужно сначала ответить на вопросы: кто может делать edit/delete, кто смотрит логи по этим операциям, надо ли этому товарищу знать предыдущее значение при выполнении редактирования, надо ему ли знать данные удаленной записи.
Практика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Полное логирование всех изменений требуется очень в ограниченных случаях и там лучше создать хистори для отдельной таблицы и сносить в нее запись целиком (или только некоторые поля) при выполнении определенных действий.
...
Рейтинг: 0 / 0
22.08.2005, 15:25
    #33228148
PVP
PVP
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
4321 PVPНа триггерах не выйдет. При удалении записи они не знают имя пользователя, который выполняет действие. В записях в этот момент код старого пользователя.кхмм. не подскажете эту чудо-субд, в которой сыршенно невозможно выяснить текущего пользователя? (не важно, раздельна у вас идентификация в субд и в клиенте, или нет)Это чудо MS SQL 2000. Windows Authentication.
Какая функция или глобальная переменная, доступные в триггере, дают информацию о userе, который удалил запись, находящуюся в deleted?
...
Рейтинг: 0 / 0
22.08.2005, 16:22
    #33228334
tygra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
LaoxДля каждой таблицы нужно сначала ответить на вопросы: кто может делать edit/delete,
Это проблемы прав в системе, а не логирования
автор кто смотрит логи по этим операциям, надо ли этому товарищу знать предыдущее значение при выполнении редактирования, надо ему ли знать данные удаленной записи.
И это тоже.
авторПрактика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Вы по-русски уж, а то бред какой-то, особенно про удаление.
авторПолное логирование всех изменений требуется очень в ограниченных случаях и там лучше создать хистори для отдельной таблицы и сносить в нее запись целиком (или только некоторые поля) при выполнении определенных действий.
А вот это правильно. Так и надо делать. И я так и делаю. :)

-- Tygra's --
...
Рейтинг: 0 / 0
22.08.2005, 16:41
    #33228393
4321
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
PVPЭто чудо MS SQL 2000. Windows Authentication.
Какая функция или глобальная переменная, доступные в триггере, дают информацию о userе, который удалил запись, находящуюся в deleted?мдя. Мои саболезнования. А что, кстати сказать, вернет
SELECT CURRENT_USER
в этом случае?
(любопытно, простите, - давненько я Т-скуль не ковырял)
...
Рейтинг: 0 / 0
22.08.2005, 17:10
    #33228476
YBW
YBW
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
tygra авторПрактика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Вы по-русски уж, а то бред какой-то, особенно про удаление.
-- Tygra's --

ИМХО типовая схема типовой подход - и так все понятно
...
Рейтинг: 0 / 0
22.08.2005, 17:58
    #33228631
Laox
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
YBW tygra авторПрактика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Вы по-русски уж, а то бред какой-то, особенно про удаление.
-- Tygra's --

ИМХО типовая схема типовой подход - и так все понятно

Ну видимо товарисчу требуетсяч перевод:
1. "Кто папа" - означает "кто последний редактировал запись". В том случае, если имеется n (где n>1) равноправных пользователей, которые могут изменять некоторое поле, неважно знать какое значение было раньше, но важно знать кто последний выполнил апдейт.
2. "Кто накосячил" - означает "кто удалил эту сверхважную запись". В том случае, если имеется n (где n>1) равноправных пользователей которые могут удалять записи, но есть при этом один суперпользователь, который принимает окончательное решение об удалении записи, важно, чтобы случайно не удалили нужную запись. В этом случае простые пользователи ничего не удаляют, а только скидывают в "корзину". А уже суперпользователь выполняет аудит этой корзины и окончательно принимает решение об удалении или восстановлении той или иной записи.
К каждой таблице хистори вешать - замучаешься таблицы создавать :)
...
Рейтинг: 0 / 0
22.08.2005, 20:21
    #33228881
PVP
PVP
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
4321А что, кстати сказать, вернет
SELECT CURRENT_USER
в этом случае?Он вернет dbo
...
Рейтинг: 0 / 0
23.08.2005, 10:22
    #33229297
tygra
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Протоколирование изменений в БД
авторНу видимо товарисчу требуетсяч перевод:
Точно! :))

Тока я не вижу смысла в таком виде якобы "логирования". Лучше ничего, чем так.

авторК каждой таблице хистори вешать - замучаешься таблицы создавать :)
Так хранимую процедуру напишите да и все. Вы что же, руками чтоли создаете?
Зачем уж так. У меня все из интерфейса - список таблиц, какую нужно логировать, нажал на кнопочку - все создалось, и таблица истории, и триггеры, и все что нужно. И даже пишется лог, когда и кто запустил/остановил логирование. И можно посмотреть лог изменений по дате.

ЗЫ Не, найду время и выложу эту хрень. Пусть кому-то будет легче.

-- Tygra's --
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Протоколирование изменений в БД / 25 сообщений из 69, страница 1 из 3
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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