Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 3 4 5 вперед Ctrl→ все |
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] Ответить | Цитировать Сообщить модератору |
МуМу Member Откуда: Сообщений: 1134 |
Вы смешали два вопроса. Вопрос авторизации и вопрос способов хранения и предоставления данных. По первому вопросу нужно исходить из того что это за система. Если это сервер приложения то нужно писать линк таблицу куда писать соответствие Spid и пользователя и по ней делать сопоставление. Но в некоторых системах это может быть проблематично когда spid меняется и управлять этим нельзя или сложно(например 1С). Второй вопрос хранения и представления. Вы можете писать триггерами чего угодно но это приведет к хранению избыточных данных(их будет много) и доп. нагрузке на систему. К тому же таблицы меняют свою структуру и нужно думать о вопросах удобного отображения истории изменений. На практике все об системе логирования кричат когда что то важное кто то поменял, включается режим паранои и т.п. Но со временем истерия утихает а вопрос нафига столько(и где) исторических данных хранить остается. Поэтому как правило определяются с минимальным набором данных и их логируют. Системы тотального лоигрования как правило не взлетают а точнее живут недолго. |
9 апр 19, 16:16 [21857365] Ответить | Цитировать Сообщить модератору |
МуМу Member Откуда: Сообщений: 1134 |
Писали коммерческие системы по логированию(для 1С) спрос не оправдал ожиданий. Точнее говорят об этом много а покупают мало.:) Исходя из этого делюсь своим опытом. А так то например динамик SQL по автогенерации триггеров и вперед! |
9 апр 19, 16:20 [21857374] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
МуМу, вы как раз попали в самую точку "spid меняется и управлять этим нельзя или сложно(например 1С). " столкнулся с такой проблемой но на MSSQL , не знаю как обойти или использовать другой подход например добавить поле с именем пользователя который редактировал |
9 апр 19, 16:28 [21857390] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
МуМу, "spid меняется и управлять этим нельзя или сложно. " есть ли примеры как с ним работать или подходы по проектированию ( для моей задачи что бы точно определить пользователя не хватает одного параметра spid , пытался использовать еще время и логин учетки тоже есть проблемы) |
9 апр 19, 16:50 [21857430] Ответить | Цитировать Сообщить модератору |
Критик Member Откуда: Москва / Калуга Сообщений: 34723 Блог |
Темпоральные таблицы |
9 апр 19, 17:04 [21857454] Ответить | Цитировать Сообщить модератору |
МуМу Member Откуда: Сообщений: 1134 |
Ну как вариант , создавайте временную таблицу в начале сеанса и пишите имя пользователя.(будет spid,время, пользователь). Надеюсь вы помните что триггеры после реструктуризации будут слетать, в случае корявой архитектуры могут пойти блокировки и просадка производительности. А лучше пишите средствами 1С осознанно что нужно - куда нужно.(ну да обработки, тоже нужно учитывать) Попомните мои слова - все остальное не взлетит. Точнее не будет стоить результат потраченного времени и будет со временем на полке пылиться. |
9 апр 19, 17:30 [21857497] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Kyvaldenius, лучшее решение - темпоральные таблицы. |
9 апр 19, 17:49 [21857554] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
Владислав Колосов, темпоральные таблицы используются в SQL Server (начиная с 2016) как быть с более ранними версиями ? |
10 апр 19, 10:33 [21858030] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
cdc |
||
10 апр 19, 10:33 [21858032] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
cdc - что это? |
||||
10 апр 19, 10:38 [21858038] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
у гугла спросите |
||||
10 апр 19, 10:39 [21858041] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
TaPaK, гугл отвечает: 1)Centers for Disease Control and Prevention 2)Славянские Домашние Сети: Главная 3)Центры по контролю и профилактике заболеваний США - Википедия 4)Работа в CDC - вакансии CDC 3118969 | Rabota.ua |
10 апр 19, 10:42 [21858047] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
беда с этими аграриями... "sql cdc" |
||
10 апр 19, 10:44 [21858050] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
TaPaK, "sql cdc" -спасибо за совет но это кардинально другой подход от имеющегося есть ли примеры /статьи по том как коректно использовать spid (имеется в виду в вязке с несколькими значениями ) |
10 апр 19, 11:22 [21858092] Ответить | Цитировать Сообщить модератору |
.Евгений Member Откуда: Сообщений: 653 |
Я не специалист по 1С, поэтому высказываюсь с предположительной интонацией: слышал, что в ней есть механизмы интеграции с шиной. В принципе поймать и сохранить сообщение (или его часть) в лог (любой формы) - дело нехитрое. |
10 апр 19, 11:56 [21858120] Ответить | Цитировать Сообщить модератору |
Kyvaldenius Member Откуда: Сообщений: 107 |
.Евгений, столкнулся с такой проблемой но на MSSQL ( 1с не используется ) |
10 апр 19, 12:56 [21858199] Ответить | Цитировать Сообщить модератору |
Владислав Колосов Member Откуда: Сообщений: 8316 |
Kyvaldenius, создаете дополнительную таблицу, в которую триггером из основной таблицы сохраняете любые параметры - время, пользователя, хост, SPID что угодно. Включаете на эту таблицу механизм отслеживания, как и на основную. Затем, при разборе CDC данных связываете по LSN. Дополнительную таблицу необходимо периодически чистить. |
10 апр 19, 13:04 [21858218] Ответить | Цитировать Сообщить модератору |
ldfanate Member Откуда: Сообщений: 226 |
Возможно не следует накапливать "историю всего подряд" средствами чисто СУБД? Ведь та задача, которую вкратце озвучил автор, зачастую означает журналирование только тех полей, которые пользователь ручками ведёт, - чтобы получить объективные доказательства действий в системе. Т.е. если в таблице только 3 поля вводятся с экранной форме, а остальные 20 - технические или вычисляемые поля, то наверное для общей производительности системы будет лучше, если на бизнес-логику приложения возложить обязанности корректно заполнять таблицы истории адресно (при сохранении бизнес-документа). |
10 апр 19, 13:21 [21858247] Ответить | Цитировать Сообщить модератору |
uaggster Member Откуда: Сообщений: 952 |
Выделите изменяемые поля в отдельную таблицу со связью 1 к 1, а потом CDC или темпоральные таблицы :-) |
||
10 апр 19, 13:46 [21858279] Ответить | Цитировать Сообщить модератору |
Arm79 Member Откуда: МО, Раменское Сообщений: 3692 |
Может не в тему, или я отстал от жизни, но разве вставка записей в лог таблицу через триггер в случае отката транзакции не будет отменена? |
10 апр 19, 14:06 [21858311] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Это определяется бизнес-требованиями. Однако, ИМХО лучше логировать именно всё подряд, потому что так проще разбирать, что там и как поменялось внутри системы, а не только что делал пользователь.
Если надо логировать действия пользователя в клиенте, независимо от работы с базой, лучше это делать в самом клиенте, локально. Но это нужно только для технарей из поддержки, т.к. обычно важны именно изменения в БД. |
||||
10 апр 19, 14:22 [21858328] Ответить | Цитировать Сообщить модератору |
ldfanate Member Откуда: Сообщений: 226 |
Это понятно. Просто при коммите триггером бизнес-документа будет вместо N записей (заголовок + позиции + хзчегоещё) в одной транзакции коммитится N+M записей истории (где M можеть быть велико, если желают много критичных полей отслеживать). Т.е. нагрузка на СУБД из расчёта на 1 комит возрастёт. А если в бизнес-логику вынести на клиент, то можно двухфазно комитить - сначала сам документ (критичные данные), потом неспеша историю (менее критичные). Сохраняться будет дольше, но зато общая нагрузка на систему будет равномернее, и СУБД не так будет нагружаться. Чтото подобное в промышленных ERP (SAP например) применяется, как способ разгрузки СУБД, когда в ней много клиентов толкутся. |
||
10 апр 19, 14:35 [21858355] Ответить | Цитировать Сообщить модератору |
invm Member Откуда: Москва Сообщений: 9633 |
|
||
10 апр 19, 14:42 [21858368] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31779 |
Нужно на одно изменение строки записывать одну строку истории. Таблица логирования делается как копия логируемой таблицы (точнее, те поля, которые вы решили логировать), плюс метаданные (кто, когда) То есть триггер всегда такой (псевдокод): 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 | ![]() |