Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Варианты логирования изменения данных / 25 сообщений из 109, страница 1 из 5
  1  все
09.04.2019, 15:46
    #39798848
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
День добрый.
Прошу разъяснения, статьи, примера, совета.

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

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


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

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


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

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

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

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

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


Лучшим считаю 1 способ но в нем возникает проблема-как на основе триггеров получить информацию о пользователе который совершил изменение (все пользователи подключаются к бд под одинаковым лог/паролем)????
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 16:16
    #39798881
МуМу
МуМу
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Вы смешали два вопроса. Вопрос авторизации и вопрос способов хранения и предоставления данных. По первому вопросу нужно исходить из того что это за система. Если это сервер приложения то нужно писать линк таблицу куда писать соответствие Spid и пользователя и по ней делать сопоставление. Но в некоторых системах это может быть проблематично когда spid меняется и управлять этим нельзя или сложно(например 1С).
Второй вопрос хранения и представления. Вы можете писать триггерами чего угодно но это приведет к хранению избыточных данных(их будет много) и доп. нагрузке на систему. К тому же таблицы меняют свою структуру и нужно думать о вопросах удобного отображения истории изменений.

На практике все об системе логирования кричат когда что то важное кто то поменял, включается режим паранои и т.п. Но со временем истерия утихает а вопрос нафига столько(и где) исторических данных хранить остается. Поэтому как правило определяются с минимальным набором данных и их логируют. Системы тотального лоигрования как правило не взлетают а точнее живут недолго.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 16:20
    #39798887
МуМу
МуМу
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Писали коммерческие системы по логированию(для 1С) спрос не оправдал ожиданий. Точнее говорят об этом много а покупают мало.:) Исходя из этого делюсь своим опытом. А так то например динамик SQL по автогенерации триггеров и вперед!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 16:28
    #39798895
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
МуМу,
вы как раз попали в самую точку
"spid меняется и управлять этим нельзя или сложно(например 1С). " столкнулся с такой проблемой но на MSSQL , не знаю как обойти или использовать другой подход например добавить поле с именем пользователя который редактировал
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 16:50
    #39798912
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
МуМу,

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


( для моей задачи что бы точно определить пользователя не хватает одного параметра spid , пытался использовать еще время и логин учетки тоже есть проблемы)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 17:04
    #39798923
Критик
Критик
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Темпоральные таблицы
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 17:30
    #39798945
МуМу
МуМу
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Ну как вариант , создавайте временную таблицу в начале сеанса и пишите имя пользователя.(будет spid,время, пользователь). Надеюсь вы помните что триггеры после реструктуризации будут слетать, в случае корявой архитектуры могут пойти блокировки и просадка производительности. А лучше пишите средствами 1С осознанно что нужно - куда нужно.(ну да обработки, тоже нужно учитывать) Попомните мои слова - все остальное не взлетит. Точнее не будет стоить результат потраченного времени и будет со временем на полке пылиться.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
09.04.2019, 17:49
    #39798968
Владислав Колосов
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Kyvaldenius,

лучшее решение - темпоральные таблицы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:33
    #39799194
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Владислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:33
    #39799195
TaPaK
TaPaK
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
KyvaldeniusВладислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?
cdc
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:38
    #39799197
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
TaPaKKyvaldeniusВладислав Колосов,

темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ?
cdc
cdc - что это?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:39
    #39799198
TaPaK
TaPaK
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
KyvaldeniusTaPaKпропущено...

cdc
cdc - что это?
у гугла спросите
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:42
    #39799200
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
TaPaK,
гугл отвечает:
1)Centers for Disease Control and Prevention
2)Славянские Домашние Сети: Главная
3)Центры по контролю и профилактике заболеваний США - Википедия
4)Работа в CDC - вакансии CDC 3118969 | Rabota.ua
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 10:44
    #39799202
TaPaK
TaPaK
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
KyvaldeniusTaPaK,
гугл отвечает:
1)Centers for Disease Control and Prevention
2)Славянские Домашние Сети: Главная
3)Центры по контролю и профилактике заболеваний США - Википедия
4)Работа в CDC - вакансии CDC 3118969 | Rabota.ua
беда с этими аграриями...
"sql cdc"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 11:22
    #39799225
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
TaPaK,

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

есть ли примеры /статьи по том как коректно использовать spid (имеется в виду в вязке с несколькими значениями )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 11:56
    #39799242
.Евгений
.Евгений
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Я не специалист по 1С, поэтому высказываюсь с предположительной интонацией: слышал, что в ней есть механизмы интеграции с шиной. В принципе поймать и сохранить сообщение (или его часть) в лог (любой формы) - дело нехитрое.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 12:56
    #39799276
Kyvaldenius
Kyvaldenius
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
.Евгений,

столкнулся с такой проблемой но на MSSQL ( 1с не используется )
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 13:04
    #39799287
Владислав Колосов
Владислав Колосов
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Kyvaldenius,

создаете дополнительную таблицу, в которую триггером из основной таблицы сохраняете любые параметры - время, пользователя, хост, SPID что угодно. Включаете на эту таблицу механизм отслеживания, как и на основную. Затем, при разборе CDC данных связываете по LSN. Дополнительную таблицу необходимо периодически чистить.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 13:21
    #39799307
ldfanate
ldfanate
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Возможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 13:46
    #39799328
uaggster
uaggster
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
ldfanateВозможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).
Выделите изменяемые поля в отдельную таблицу со связью 1 к 1, а потом CDC или темпоральные таблицы :-)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 14:06
    #39799354
Arm79
Arm79
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Может не в тему, или я отстал от жизни, но разве вставка записей в лог таблицу через триггер в случае отката транзакции не будет отменена?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 14:22
    #39799364
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
ldfanateВозможно не следует накапливать "историю всего подряд" средствами чисто СУБД?
Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе.
Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа).Средствами чисто СУБД можно логировать и не "всё подряд".
Это определяется бизнес-требованиями.
Однако, ИМХО лучше логировать именно всё подряд, потому что так проще разбирать, что там и как поменялось внутри системы, а не только что делал пользователь.
Arm79Может не в тему, или я отстал от жизни, но разве вставка записей в лог таблицу через триггер в случае отката транзакции не будет отменена?Будет, но речь же о логировании изменений в системе.
Если надо логировать действия пользователя в клиенте, независимо от работы с базой, лучше это делать в самом клиенте, локально.
Но это нужно только для технарей из поддержки, т.к. обычно важны именно изменения в БД.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 14:35
    #39799380
ldfanate
ldfanate
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
Выделите изменяемые поля в отдельную таблицу со связью 1 к 1, а потом CDC или темпоральные таблицы :-)
Это понятно. Просто при коммите триггером бизнес-документа будет вместо N записей (заголовок + позиции + хзчегоещё) в одной транзакции коммитится N+M записей истории (где M можеть быть велико, если желают много критичных полей отслеживать).
Т.е. нагрузка на СУБД из расчёта на 1 комит возрастёт.

А если в бизнес-логику вынести на клиент, то можно двухфазно комитить - сначала сам документ (критичные данные), потом неспеша историю (менее критичные). Сохраняться будет дольше, но зато общая нагрузка на систему будет равномернее, и СУБД не так будет нагружаться. Чтото подобное в промышленных ERP (SAP например) применяется, как способ разгрузки СУБД, когда в ней много клиентов толкутся.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 14:42
    #39799387
invm
invm
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
ldfanateТ.е. нагрузка на СУБД из расчёта на 1 комит возрастёт.commit не создает нагрузки.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
10.04.2019, 14:59
    #39799404
alexeyvg
alexeyvg
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Варианты логирования изменения данных
ldfanateЭто понятно. Просто при коммите триггером бизнес-документа будет вместо N записей (заголовок + позиции + хзчегоещё) в одной транзакции коммитится N+M записей истории (где M можеть быть велико, если желают много критичных полей отслеживать).Нет, такой схемы не надо делать.
Нужно на одно изменение строки записывать одну строку истории.
Таблица логирования делается как копия логируемой таблицы (точнее, те поля, которые вы решили логировать), плюс метаданные (кто, когда)
То есть триггер всегда такой (псевдокод):
Код: sql
1.
2.
3.
insert Table_log(login, date, fields...)
select @current_login, @current_date, fields...
from inserted

И всё.
Нагрузка нулевая.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Варианты логирования изменения данных / 25 сообщений из 109, страница 1 из 5
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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