там есть много тонких непонятных моментов
как по таблице tablesForLogging создать скрипт для восстановления и заполнить его данными из tableLoggingData?
это тебе непонятно или что-то еще?
Все там понятно, просто убогая архитектура и куча дырок. Задача чисто синтетического плана.
Собственнно что я им ответил
[23:07, 21.09.2022] Konstantin: я им сказал что архитектура которая вынуждает заниматься динамическими скулями убогая. и решение хоть и есть тоже неэффективное. и что решить можно но не хотелось бы потому я не согласен с таким универсальным архитектурным решением
[23:07, 21.09.2022] Konstantin: касаемо триггера, я обычно правда не любил когда в лог попадают и инсерты тоже. потому как как там правильно показано приходится по типам различать. но над ним может надо подумать отдельно. но скажем если дают ID записи вставки именно новой строки то есть типа 0 то ее нет смысла восстанавливать потому что когда она была одна она не менялась, а когда в строке целевой таблицы что то изменится появится еще одна строка лога и ее надо будет восстанавливать. вообще я не считаю правильным в одном логе хранить и данные совпадающие со строкой логированной таблицы и и ее старые данные. если необходимо хранить факт инсерта и нельзя его отметить через InsertDate в целевой таблице то стоит хранить думаю ПЕРВУЮ запись в виде NULL в джисоновском поле. но это личное мое мнение
[23:08, 21.09.2022] Konstantin: асаемо организации то что мне не очень нравится подобное логирование в JSON потому что усложняет восприятие хотя и дает универсиализацию это наверно лично мое мнение может чем то это и хорошо, хотя я сомневаюсь что тяжелые варчары это хорошо. скорее вопрос в другом. разворачивание JSON-А OpenSON-ом это известная вещь. но там надо ЗАРАНЕЕ знать имена колонок и пути в файле соответственно. если этого не знать то мы получим столбец имен колонок значений и типов потом мы можем развернуть это в две строчки функцией и использовать динамический SQL далее для добавления (тем более что все равно мы изначально не знаем имени таблицы и базы)
[23:08, 21.09.2022] Konstantin: динамический скуль это вообще не очень хорошо он имеет неприятные нюансы . кроме того у нас в логе есть ID и больше этого ID нигде нет. если мы решили забиццо на ID то можно использовать системные sys.all_objects и sys.databases.
[23:08, 21.09.2022] Konstantin: если ID в целевой таблице это Identity то вставка в это поле возможно только при предварительном запуске специальной директивы. (если запись скажем уже удалена) таким образом решение как будто искуственно усложнено чтобы понять что человек знает о джисоне и динамическом скуле. но с точки зрения продуктива я такие решения как человек с 20 летним опытом не одобряю ибо унификация хорошо но тут она на мой взгляд дается слишком большой ценой. Но если в данном случае это жесткая идея я попробую вам описанное выразить в коде. но повторюсь. я считаю это технологически и архитектурно неправильным решением
[23:08, 21.09.2022] Konstantin: И кстати еще на тему триггера и аудита. Смысл аудита/лога в чем? фиксировать изменения в таблице которые так или иначе в целевой таблице будут утрачены. таким образом рассмотрим ситуацию. Предположим что для однообразия мы будем хранить в таблице лога только ПРЕДЫДУЩИЕ данные, это отлично подходит для апдейта и делита. ВОпрос с инсертом. для инсерта как таковых предыдущих данных нет и мы пишем скажем нулл. таким образом мы в логе фиксируем что некий процесс или пользователь внес изменения в целевую таблицу. а какие? а можно посмотреть в целевую таблицу, ведь мы и в случае апдейта и делита НЕ храним новые значения в логе они есть ТОЛЬКО в целевой таблице до тех пор пока не будут оттуда удалены или там изменены. Зачем для инсерта менять этот подход. Ладно можем возразить а ведь кто то изменит эти данные и мы не узнаем больше что вставлял ТОТ САМЫЙ ПЕРВЫЙ. Не-а УЗНАЕМ потому что ТА САМАЯ ПЕРВАЯ запись будет положена в лог при первом же изменении. это ЛОГ ИЗМЕНЕНИЙ!! он не решает задачу восстановления данных после транкейта таблицы. для этого должны быть бэкапы.
