|
SQL / Задача для срача
#158964
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
Ссылка на вложение:
|
||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
#18+
Задачка в аттаче. На мой взгляд весьма неоднозначная. ... |
||||||||||||||||
:
Нравится:
Не нравится:
|
||||||||||||||||
22.09.2022, 07:39 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
Сириус палюбому должен знать как решать. он же у нас фуллстек. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 07:39 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
Есть такое хранилище логов USE [LogDB] GO /****** Object: Table [dbo].[tablesForLogging] Script Date: 31.08.2021 10:45:47 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- конфиг таблицы, что логируем CREATE TABLE [dbo].[tablesForLogging]( [BaseName] [nvarchar](50) NULL, [tableName] [nvarchar](50) NULL, [Field_Key] [nvarchar](100) NULL, [is_active] [bit] NULL, [Storage] [int] NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[tablesForLogging] ADD CONSTRAINT [DF_TablesForLogging_is_active] DEFAULT ((1)) FOR [is_active] GO USE [LogDB] GO /****** Object: Table [dbo].[tableLoggingData] Script Date: 31.08.2021 10:46:02 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- сами залогированные данные CREATE TABLE [dbo].[tableLoggingData]( [id] [bigint] IDENTITY(1,1) NOT NULL, [Base_ID] [bigint] NOT NULL, [table_ID] [bigint] NOT NULL, [DateAdd] [datetime] NOT NULL, [is_type] [bit] NOT NULL, [HostName] [varchar](100) NULL, [ProgramName] [varchar](100) NULL, [Proc_ID] [bigint] NULL, [SystemUser] [varchar](50) NULL, [Str_json] [nvarchar](max) NULL ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO GO Use [SomeAbstractDB] go на какой-то абстрактной таблице есть триггер CREATE TRIGGER [dbo].[LogAction_tt_online_services] ON [dbo].[SomeAbstractTable] AFTER DELETE,UPDATE,INSERT AS BEGIN IF EXISTS (SELECT * FROM deleted) BEGIN INSERT INTO LogDB.dbo.TableLoggingData (Base_ID, Table_ID, [DateAdd], is_type, HostName, ProgramName, Proc_ID, SystemUser, Str_json) SELECT 23, 485330533, GETDATE(), 1, HOST_NAME(), PROGRAM_NAME(), @@PROCID, SYSTEM_USER, (SELECT D.* FOR JSON PATH) FROM deleted D END IF EXISTS (SELECT * FROM inserted) AND NOT EXISTS(SELECT * FROM deleted) BEGIN INSERT INTO LogDB.dbo.TableLoggingData (Base_ID, Table_ID, [DateAdd], is_type, HostName, ProgramName, Proc_ID, SystemUser, Str_json) SELECT 23, 485330533, GETDATE(), 0, HOST_NAME(), PROGRAM_NAME(), @@PROCID, SYSTEM_USER, (SELECT I.* FOR JSON PATH) FROM inserted I END END Задача: 1) Сделать процедуру восстановления данных, которая на вход принимает айдишник из таблицы TableLoggingData и в целевой таблице восстанавливает запись 2) Может что-то можно\нужно изменить в триггере ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 09:12 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
Задача: 1) Сделать процедуру восстановления данных, которая на вход принимает айдишник из таблицы TableLoggingData и в целевой таблице восстанавливает запись за деньги зы: не забудь перед восстановлением отключить нахуй триггер ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 11:03 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
2) Может что-то можно\нужно изменить в триггере ? логи они как бы не для восстановления, а для анализа. для восстановления гораздо удобнее использовать другие механизмы. например бэкапы. 1) Сделать процедуру восстановления данных, которая на вход принимает айдишник из таблицы TableLoggingData и в целевой таблице восстанавливает запись ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 11:04 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
там есть много тонких непонятных моментов это тебе непонятно или что-то еще? Собственнно что я им ответил [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: И кстати еще на тему триггера и аудита. Смысл аудита/лога в чем? фиксировать изменения в таблице которые так или иначе в целевой таблице будут утрачены. таким образом рассмотрим ситуацию. Предположим что для однообразия мы будем хранить в таблице лога только ПРЕДЫДУЩИЕ данные, это отлично подходит для апдейта и делита. ВОпрос с инсертом. для инсерта как таковых предыдущих данных нет и мы пишем скажем нулл. таким образом мы в логе фиксируем что некий процесс или пользователь внес изменения в целевую таблицу. а какие? а можно посмотреть в целевую таблицу, ведь мы и в случае апдейта и делита НЕ храним новые значения в логе они есть ТОЛЬКО в целевой таблице до тех пор пока не будут оттуда удалены или там изменены. Зачем для инсерта менять этот подход. Ладно можем возразить а ведь кто то изменит эти данные и мы не узнаем больше что вставлял ТОТ САМЫЙ ПЕРВЫЙ. Не-а УЗНАЕМ потому что ТА САМАЯ ПЕРВАЯ запись будет положена в лог при первом же изменении. это ЛОГ ИЗМЕНЕНИЙ!! он не решает задачу восстановления данных после транкейта таблицы. для этого должны быть бэкапы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 11:34 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
там есть много тонких непонятных моментов это тебе непонятно или что-то еще? база-таблица-первичный ключ- активность логирования но если ты заметишь она не связана с tableLoggingData ключами если только ID Это не имя таблицы гыыы Так что использовать ее для чего либо невозможно. были бы там какие то связующие ключи да. можно было данные использовать из лога. а таблицу базу искать в этой таблице. а сейчас как предлагаешь сопоставить ID таблицы из лога с именем таблицы в той таблице? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 11:40 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
там есть много тонких непонятных моментов это тебе непонятно или что-то еще? Собственнно что я им ответил [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: И кстати еще на тему триггера и аудита. Смысл аудита/лога в чем? фиксировать изменения в таблице которые так или иначе в целевой таблице будут утрачены. таким образом рассмотрим ситуацию. Предположим что для однообразия мы будем хранить в таблице лога только ПРЕДЫДУЩИЕ данные, это отлично подходит для апдейта и делита. ВОпрос с инсертом. для инсерта как таковых предыдущих данных нет и мы пишем скажем нулл. таким образом мы в логе фиксируем что некий процесс или пользователь внес изменения в целевую таблицу. а какие? а можно посмотреть в целевую таблицу, ведь мы и в случае апдейта и делита НЕ храним новые значения в логе они есть ТОЛЬКО в целевой таблице до тех пор пока не будут оттуда удалены или там изменены. Зачем для инсерта менять этот подход. Ладно можем возразить а ведь кто то изменит эти данные и мы не узнаем больше что вставлял ТОТ САМЫЙ ПЕРВЫЙ. Не-а УЗНАЕМ потому что ТА САМАЯ ПЕРВАЯ запись будет положена в лог при первом же изменении. это ЛОГ ИЗМЕНЕНИЙ!! он не решает задачу восстановления данных после транкейта таблицы. для этого должны быть бэкапы. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 11:41 |
|
SQL / Задача для срача
|
|||
---|---|---|---|
#18+
У меня основная претензия к ненужной универсиализации. зачем делать на сотни таблиц один лог? потому что тогда не надо хранить содержимое табличек в джисонах или в режиме поле-значение что облегчает извлечение. потому что это вообще ускоряет работу с аудитом ну и терабайтная таблица она все равно терабайтная как ни крути. поэтому я против такой неудобной универсиализации. но дело вкуса. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2022, 13:57 |
|
|
Start [/forum/search.php?do_search=1&tid=4705&author_mode=wrote_post&author=Doublekey&start_from=158965]: |
0ms |
get settings: |
1ms |
get forum list: |
4ms |
searching: |
9ms |
get settings: |
1ms |
get forum list: |
4ms |
get topic data: |
3ms |
check forum access: |
0ms |
check topic access: |
0ms |
get forum data: |
0ms |
get found posts: |
23ms |
track hit: |
35ms |
get online users: |
71ms |
check new: |
1ms |
others: | 291ms |
total: | 443ms |
0 / 0 |