Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Всем привет!

Интересен опыт кто и как реализовал у себя логирование изменений в таблицах

Я создаю копию таблицы с дополнительными четырьмя столбцами
event: значения I, U, D - по типу операции
edatetime: дата действия
euser: кто вносил изменения
ehost: с какого хоста.

В триггере делаю инсерт в лог таблицу.

У кого какие варианты логирования ?
23 май 13, 15:36    [14339435]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
CDC
Guest
Используем CDC. Вот только не помню, есть ли там хост
23 май 13, 15:54    [14339632]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
iap
Member

Откуда: Москва
Сообщений: 47001
CDC
Используем CDC. Вот только не помню, есть ли там хост
Там, если не ошибаюсь, записать того, кто удалил, не получится?
23 май 13, 15:57    [14339671]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
iap
Member

Откуда: Москва
Сообщений: 47001
Testor1
В триггере делаю инсерт в лог таблицу.
Самое интересное - в деталях.
Например, заче логировать INSERT?
Вставлять в лог записи, которые затронула операция UPDATE или DELETE
или же только записи, в которых реально изменились данные?

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

То есть, от задачи очень зависит.
Интересно также прочитать слегка устаревшую статью: Журналирование изменений структуры БД и данных
23 май 13, 16:03    [14339730]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Cammomile
Member

Откуда:
Сообщений: 1214
http://www.compdoc.ru/bd/sql/log_change_of_structure_bd/

Весьма подробный мануал
23 май 13, 16:13    [14339797]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Cammomile
http://www.compdoc.ru/bd/sql/log_change_of_structure_bd/

Весьма подробный мануал

Какой-то левый сайт с всплывающими "антивирусами", рекламами и прочей хренью.
"Подробный мануал", ожидаемо, оказался копией "слегка устаревшей статьи" с sql.ru.
23 май 13, 16:22    [14339862]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Иногда приходиться делать перерасчет исторических данных за период, а за этот период клиенты могли быть уже удалены из основной таблицы, поэтому удобно делать перерасчет по лог таблице. на конкретную дату я могу получить последний статус клиента.
23 май 13, 16:35    [14339936]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Иногда приходиться делать перерасчет исторических данных за период, а за этот период клиенты могли быть уже удалены из основной таблицы, поэтому удобно делать перерасчет по лог таблице. на конкретную дату я могу получить последний статус клиента.

Зачем тогда хранить историю в отдельной таблице, а не в ней самой же ?
23 май 13, 16:40    [14339959]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Иногда приходиться делать перерасчет исторических данных за период, а за этот период клиенты могли быть уже удалены из основной таблицы, поэтому удобно делать перерасчет по лог таблице. на конкретную дату я могу получить последний статус клиента.

Зачем тогда хранить историю в отдельной таблице, а не в ней самой же ?


Уже не помню. Была причина. Кажись из-за редактирования данных о клиенте. Нужно было бы не редактировать запись в таблице, а всегда делать инсерт.
23 май 13, 16:43    [14339980]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Уже не помню. Была причина. Кажись из-за редактирования данных о клиенте. Нужно было бы не редактировать запись в таблице, а всегда делать инсерт.

Ну так это наоборот способствует хранению в одной таблице
Редактируемая запись "закрывается", новая - добавляется
23 май 13, 16:45    [14339989]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Testor1
клиенты могли быть уже удалены из основной таблицы

Как правило, это плохая практика и свидетельство кривого дизайна БД...
23 май 13, 16:47    [14340008]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Гость333
Testor1
клиенты могли быть уже удалены из основной таблицы

Как правило, это плохая практика и свидетельство кривого дизайна БД...


Не отрицаю. Давно было и ни кто не рождается спецом. Предлагаете все хранить в одной таблице инфо о клиенте и все изменения о нем?
23 май 13, 16:53    [14340045]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Уже не помню. Была причина. Кажись из-за редактирования данных о клиенте. Нужно было бы не редактировать запись в таблице, а всегда делать инсерт.

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


Как в этом случае делать Primary_key по клиенту если id уже не будет уникальным ?
23 май 13, 16:54    [14340056]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Glory
пропущено...

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


Как в этом случае делать Primary_key по клиенту если id уже не будет уникальным ?

Мммм, также как при вашем "Нужно было бы не редактировать запись в таблице, а всегда делать инсерт" ?
23 май 13, 17:01    [14340087]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
пропущено...


Как в этом случае делать Primary_key по клиенту если id уже не будет уникальным ?

Мммм, также как при вашем "Нужно было бы не редактировать запись в таблице, а всегда делать инсерт" ?

Сорри не понял ответа. Поясни.
23 май 13, 17:02    [14340093]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
Сорри не понял ответа. Поясни.

Вы написали
"Нужно было бы не редактировать запись в таблице, а всегда делать инсерт"
Т.е. вы делалил инсерт при оставшейся записи с Primary_key по клиенту
Как вы это делали ?
23 май 13, 17:12    [14340139]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
Сорри не понял ответа. Поясни.

Вы написали
"Нужно было бы не редактировать запись в таблице, а всегда делать инсерт"
Т.е. вы делалил инсерт при оставшейся записи с Primary_key по клиенту
Как вы это делали ?


В моей схеме
в основной таблице актуальная информация и на ней можно поставить primary key для контроля целостности

в случае лог таблицы при перерасчете получаю актуальную запись по клиенту на момент события.

select TOP 1 @records...
FROM clients
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC
23 май 13, 17:27    [14340214]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Testor1
Glory
пропущено...

Вы написали
"Нужно было бы не редактировать запись в таблице, а всегда делать инсерт"
Т.е. вы делалил инсерт при оставшейся записи с Primary_key по клиенту
Как вы это делали ?


В моей схеме
в основной таблице актуальная информация и на ней можно поставить primary key для контроля целостности

в случае лог таблицы при перерасчете получаю актуальную запись по клиенту на момент события.

select TOP 1 @records...
FROM clients
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC


Правильней
23 май 13, 17:27    [14340216]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Testor1
Testor1
пропущено...


В моей схеме
в основной таблице актуальная информация и на ней можно поставить primary key для контроля целостности

в случае лог таблицы при перерасчете получаю актуальную запись по клиенту на момент события.

select TOP 1 @records...
FROM clients
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC


Правильней


select TOP 1 @records...
FROM clients_log
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC

p.s.
пост случайно задублировался
23 май 13, 17:29    [14340226]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
в основной таблице актуальная информация и на ней можно поставить primary key для контроля целостности

в случае лог таблицы при перерасчете получаю актуальную запись по клиенту на момент события.

select TOP 1 @records...
FROM clients
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC

А какой PK в вашей лог таблице ? Разве client_id ?
23 май 13, 17:30    [14340233]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
в основной таблице актуальная информация и на ней можно поставить primary key для контроля целостности

в случае лог таблицы при перерасчете получаю актуальную запись по клиенту на момент события.

select TOP 1 @records...
FROM clients
WHERE client_id = @client_id
AND edatetime <= @edatetime

ORDER BY edatetime DESC

А какой PK в вашей лог таблице ? Разве client_id ?


В основой таблице client_id
НО в лог таблице не стоит Primary Key. Он там уже не нужен.
23 май 13, 17:32    [14340246]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Glory
Member

Откуда:
Сообщений: 104760
Testor1
В основой таблице client_id
НО в лог таблице не стоит Primary Key. Он там уже не нужен.

И в чем проблема тогда в предложенном мной варианте только с одной таблицей ?
23 май 13, 17:33    [14340251]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Testor1
Гость333
пропущено...

Как правило, это плохая практика и свидетельство кривого дизайна БД...


Не отрицаю. Давно было и ни кто не рождается спецом. Предлагаете все хранить в одной таблице инфо о клиенте и все изменения о нем?

В простейшем случае, в таблицу "Клиенты" добавляется признак "Удалён" (или "Неактивен", как хотите назовите). Это избавляет от необходимости удалять данные из таблицы. Преимущество — можно создать foreign keys, ссылающиеся на таблицу клиентов с других таблиц (не знаю, какие у вас есть, пусть будут какие-нибудь "Отгрузки", "Оплаты" и т.д.).

Или можно добавить в таблицу клиентов поле "Дата_Закрытия_Клиента".

Также можно вынести те атрибуты клиента, которые могут изменяться со временем, в отдельную таблицу: "Ид_Клиента", "Дата_Начала", "Дата_Конца", "Атрибут_1", ..., "Атрибут_N". И делать запросы к этой таблице с условием @НужнаяДата >= "Дата_Начала" and @НужнаяДата < "Дата_Конца"...
23 май 13, 17:37    [14340268]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
ambarka_max
Member

Откуда: Россия
Сообщений: 517
Гость333
атрибуты клиента, которые могут изменяться со временем

философский вопрос...
23 май 13, 17:39    [14340279]     Ответить | Цитировать Сообщить модератору
 Re: Логирование изменений (опыт)  [new]
Testor1
Member

Откуда:
Сообщений: 679
Glory
Testor1
В основой таблице client_id
НО в лог таблице не стоит Primary Key. Он там уже не нужен.

И в чем проблема тогда в предложенном мной варианте только с одной таблицей ?


Если cleints - становиться исторической, то на нее не возможно наложить primary_key
как я понимаю, а не спорю с тобой.
23 май 13, 17:40    [14340284]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить