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

Откуда:
Сообщений: 107
День добрый.
Прошу разъяснения, статьи, примера, совета.

Краткая задача:"Необходимо сделать историю изменений данных которая хранит сами данные действие время и пользователь который совершил действие"

Проблема состоит в следующем какой подход использовать: (опишу решения которые знаю и их достоинства не достатки )


Способы которые знаю:
1)Создать собственные таблицы для управления авторизацией ( пользователи/ группы/ объекты) и продумать действия по работе сними ( шифрование пароля/ разделение прав/объектов)

+ все в твоих руках
- не понятно как быть с логированием данных: а именно с логином пользователя
то есть стандартные функции mssql будут показывать учетку / или имя входа в MS sql
приходится делать промежуточные таблицы где есть свои проблемы (Лог изменений данных)


2) способ использовать AD то есть (microsoft authorization)
тогда логика выглядит так мы в настройках сервера SQL подключаем группу пользователей которая может подключаться к серверу бд и храним логин ( работа по шифрованию пароля / изменения ложиться на AD)

в приложении (строка подключения) прописываем авторизацию microsoft

+ меньше работы с паролем, также можно совместить с (1) указав свои группы/права/объекты
так же логирование данных будет проходить корректно так как логин пользователя= его учетке которая вызывается стандартными функциями/запросами к системным таблицам

- не всегда есть AD, ули не все пользователи занесены в домен либо еще что то связанное с администрированием

3) Авторизация с помощью sql
ни разу не пробовал если есть хорошие статьи с примерами киньте
Представления в общих чертах на подобие работы с (2) но на практике ни разу не видел
-как добавлять CRUD пользователей как быть с паролем и тд....


Лучшим считаю 1 способ но в нем возникает проблема-как на основе триггеров получить информацию о пользователе который совершил изменение (все пользователи подключаются к бд под одинаковым лог/паролем)????
9 апр 19, 15:46    [21857315]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
МуМу
Member

Откуда:
Сообщений: 1072
Вы смешали два вопроса. Вопрос авторизации и вопрос способов хранения и предоставления данных. По первому вопросу нужно исходить из того что это за система. Если это сервер приложения то нужно писать линк таблицу куда писать соответствие Spid и пользователя и по ней делать сопоставление. Но в некоторых системах это может быть проблематично когда spid меняется и управлять этим нельзя или сложно(например 1С).
Второй вопрос хранения и представления. Вы можете писать триггерами чего угодно но это приведет к хранению избыточных данных(их будет много) и доп. нагрузке на систему. К тому же таблицы меняют свою структуру и нужно думать о вопросах удобного отображения истории изменений.

На практике все об системе логирования кричат когда что то важное кто то поменял, включается режим паранои и т.п. Но со временем истерия утихает а вопрос нафига столько(и где) исторических данных хранить остается. Поэтому как правило определяются с минимальным набором данных и их логируют. Системы тотального лоигрования как правило не взлетают а точнее живут недолго.
9 апр 19, 16:16    [21857365]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
МуМу
Member

Откуда:
Сообщений: 1072
Писали коммерческие системы по логированию(для 1С) спрос не оправдал ожиданий. Точнее говорят об этом много а покупают мало.:) Исходя из этого делюсь своим опытом. А так то например динамик SQL по автогенерации триггеров и вперед!
9 апр 19, 16:20    [21857374]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
МуМу,
вы как раз попали в самую точку
"spid меняется и управлять этим нельзя или сложно(например 1С). " столкнулся с такой проблемой но на MSSQL , не знаю как обойти или использовать другой подход например добавить поле с именем пользователя который редактировал
9 апр 19, 16:28    [21857390]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
МуМу,

"spid меняется и управлять этим нельзя или сложно. " есть ли примеры как с ним работать или подходы по проектированию


( для моей задачи что бы точно определить пользователя не хватает одного параметра spid , пытался использовать еще время и логин учетки тоже есть проблемы)
9 апр 19, 16:50    [21857430]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31392
Блог
Темпоральные таблицы
9 апр 19, 17:04    [21857454]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
МуМу
Member

Откуда:
Сообщений: 1072
Ну как вариант , создавайте временную таблицу в начале сеанса и пишите имя пользователя.(будет spid,время, пользователь). Надеюсь вы помните что триггеры после реструктуризации будут слетать, в случае корявой архитектуры могут пойти блокировки и просадка производительности. А лучше пишите средствами 1С осознанно что нужно - куда нужно.(ну да обработки, тоже нужно учитывать) Попомните мои слова - все остальное не взлетит. Точнее не будет стоить результат потраченного времени и будет со временем на полке пылиться.
9 апр 19, 17:30    [21857497]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6356
Kyvaldenius,

лучшее решение - темпоральные таблицы.
9 апр 19, 17:49    [21857554]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
Владислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?
10 апр 19, 10:33    [21858030]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6142
Kyvaldenius
Владислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?

cdc
10 апр 19, 10:33    [21858032]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
TaPaK
Kyvaldenius
Владислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?

cdc

cdc - что это?
10 апр 19, 10:38    [21858038]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6142
Kyvaldenius
TaPaK
пропущено...

cdc

cdc - что это?

у гугла спросите
10 апр 19, 10:39    [21858041]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
TaPaK,
гугл отвечает:
1)Centers for Disease Control and Prevention
2)Славянские Домашние Сети: Главная
3)Центры по контролю и профилактике заболеваний США - Википедия
4)Работа в CDC - вакансии CDC 3118969 | Rabota.ua
10 апр 19, 10:42    [21858047]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6142
Kyvaldenius
TaPaK,
гугл отвечает:
1)Centers for Disease Control and Prevention
2)Славянские Домашние Сети: Главная
3)Центры по контролю и профилактике заболеваний США - Википедия
4)Работа в CDC - вакансии CDC 3118969 | Rabota.ua

беда с этими аграриями...
"sql cdc"
10 апр 19, 10:44    [21858050]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
TaPaK,

"sql cdc" -спасибо за совет но это кардинально другой подход от имеющегося

есть ли примеры /статьи по том как коректно использовать spid (имеется в виду в вязке с несколькими значениями )
10 апр 19, 11:22    [21858092]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
.Евгений
Member

Откуда:
Сообщений: 465
Я не специалист по 1С, поэтому высказываюсь с предположительной интонацией: слышал, что в ней есть механизмы интеграции с шиной. В принципе поймать и сохранить сообщение (или его часть) в лог (любой формы) - дело нехитрое.
10 апр 19, 11:56    [21858120]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Kyvaldenius
Member

Откуда:
Сообщений: 107
.Евгений,

столкнулся с такой проблемой но на MSSQL ( 1с не используется )
10 апр 19, 12:56    [21858199]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6356
Kyvaldenius,

создаете дополнительную таблицу, в которую триггером из основной таблицы сохраняете любые параметры - время, пользователя, хост, SPID что угодно. Включаете на эту таблицу механизм отслеживания, как и на основную. Затем, при разборе CDC данных связываете по LSN. Дополнительную таблицу необходимо периодически чистить.
10 апр 19, 13:04    [21858218]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
ldfanate
Member

Откуда:
Сообщений: 79
Возможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).
10 апр 19, 13:21    [21858247]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
uaggster
Member

Откуда:
Сообщений: 554
ldfanate
Возможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).

Выделите изменяемые поля в отдельную таблицу со связью 1 к 1, а потом CDC или темпоральные таблицы :-)
10 апр 19, 13:46    [21858279]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3607
Может не в тему, или я отстал от жизни, но разве вставка записей в лог таблицу через триггер в случае отката транзакции не будет отменена?
10 апр 19, 14:06    [21858311]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28168
ldfanate
Возможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).
Средствами чисто СУБД можно логировать и не "всё подряд".
Это определяется бизнес-требованиями.
Однако, ИМХО лучше логировать именно всё подряд, потому что так проще разбирать, что там и как поменялось внутри системы, а не только что делал пользователь.
Arm79
Может не в тему, или я отстал от жизни, но разве вставка записей в лог таблицу через триггер в случае отката транзакции не будет отменена?
Будет, но речь же о логировании изменений в системе.
Если надо логировать действия пользователя в клиенте, независимо от работы с базой, лучше это делать в самом клиенте, локально.
Но это нужно только для технарей из поддержки, т.к. обычно важны именно изменения в БД.
10 апр 19, 14:22    [21858328]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
ldfanate
Member

Откуда:
Сообщений: 79
Выделите изменяемые поля в отдельную таблицу со связью 1 к 1, а потом CDC или темпоральные таблицы :-)

Это понятно. Просто при коммите триггером бизнес-документа будет вместо N записей (заголовок + позиции + хзчегоещё) в одной транзакции коммитится N+M записей истории (где M можеть быть велико, если желают много критичных полей отслеживать).
Т.е. нагрузка на СУБД из расчёта на 1 комит возрастёт.

А если в бизнес-логику вынести на клиент, то можно двухфазно комитить - сначала сам документ (критичные данные), потом неспеша историю (менее критичные). Сохраняться будет дольше, но зато общая нагрузка на систему будет равномернее, и СУБД не так будет нагружаться. Чтото подобное в промышленных ERP (SAP например) применяется, как способ разгрузки СУБД, когда в ней много клиентов толкутся.
10 апр 19, 14:35    [21858355]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
invm
Member

Откуда: Москва
Сообщений: 8489
ldfanate
Т.е. нагрузка на СУБД из расчёта на 1 комит возрастёт.
commit не создает нагрузки.
10 апр 19, 14:42    [21858368]     Ответить | Цитировать Сообщить модератору
 Re: Варианты логирования изменения данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28168
ldfanate
Это понятно. Просто при коммите триггером бизнес-документа будет вместо N записей (заголовок + позиции + хзчегоещё) в одной транзакции коммитится N+M записей истории (где M можеть быть велико, если желают много критичных полей отслеживать).
Нет, такой схемы не надо делать.
Нужно на одно изменение строки записывать одну строку истории.
Таблица логирования делается как копия логируемой таблицы (точнее, те поля, которые вы решили логировать), плюс метаданные (кто, когда)
То есть триггер всегда такой (псевдокод):
insert Table_log(login, date, fields...)
select @current_login, @current_date, fields...
from inserted
И всё.
Нагрузка нулевая.
10 апр 19, 14:59    [21858391]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить