Создать на основе триггера для таблицы нечто вроде версионности данных

@RafStudio · Регистрация: 08.08.2011

Студворк — интернет-сервис помощи студентам

Допустим, есть некая таблица:

SQL
1
2
3
4
5
6
CREATE TABLE t_table(
  id INT PRIMARY KEY,
  txt1 VARCHAR(255) NOT NULL,
  txt2 VARCHAR(255) NOT NULL,
  txt3 VARCHAR(255) NOT NULL
  )

И есть таблица:

SQL
1
2
3
4
5
CREATE TABLE version(
  id INT PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  version INT NOT NULL
  )

Суть вопроса: помочь написать триггер на добавление, изменение и удаление данных из таблицы t_table, чтобы тот всякий раз изменял в таблице version в строке с именем базы (столбец name) значение на 1. То есть изменились данные, хоть 1 строка, хоть миллион, в таблице version для этой таблицы видим, что было например 63 стало 64, соответственно в прикладном приложении принимаем решение о необходимости нового кэширования данных в локальной базе (дабы не бомбить SQL сервер). Простите, в MS SQL работаю с элементарными вещами, а с триггерами как то для меня пока сложновато...
Заранее спасибо!

@Andrey-MSK · 13.10.2021, 17:30

RafStudio,
А вам для чего? Если просто сохранить данные и не переписать более новые при редактировании, то используйте вот это:
rowversion (Transact-SQL)

@RafStudio · 13.10.2021, 18:38 **[ТС]**

Спасибо за потраченное время. В указанном примере как бы вроде то, но на деле параметр отвечает именно за строки в таблице, а не именно за всю таблицу...
Я так понимаю, не до конца ясен смысл того, что я пытаюсь нагородить. Поясню:
Пишу приложение обслуживающее запросы с мобильных и вообще Web клиентов. Предполагается туча запросов в некий промежуток времени. Так или иначе они, эти запросы, затрагивают множество связанных таблиц MS SQL. Понятное дело, есть таблицы оперативного доступа к реальному положению вещей в текущий момент времени. Например - баланс на бонусной карте, номер карты и прочее. Однако, есть базовые таблицы, проще говоря - справочники, содержание которых может измениться раз в год, некоторых раз в сутки и т.п. Поскольку они являются справочниками, то обращение к ним зачастую неизбежно частое, если не сказать, что практически постоянное в каждом важном запросе. Ради такого "счастья" не вижу необходимости насиловать основной SQL сервер. Можно кэшировать информацию из таблиц SQL сервера в локальные базы и получать информацию по справочникам из них. Ясен пень - вопрос тонкий и требует внимательного рассмотрения плюсов и минусов. Но, скажем так, я уже определился с тем, что мне нужно в кэшированном виде. Следующим шагом встаёт вопрос синхронизации этих таблиц разок да в течении некоторого количества времени. Можно жёстко выполнять UPSERT локальных таблиц по таймеру, не взирая на то - были на сервере изменения или нет. Но, мне так кажется, это несколько жестоко. Именно поэтому пришла в голову мысль - хранить на сервере для необходимых таблиц версию текущих данных, которая всякий раз будет изменяться (допустим увеличиваться) при ЛЮБОМ изменении данных контролируемой таблицы. Ещё раз подчеркну - контролируемые таблицы являются справочниками и активное частое их ИЗМЕНЕНИЕ не подразумевается в принципе. Раз в час не считаю активным изменением. Таким образом можно организовать из приложения, скажем так раз в минуту, опрос одной единственной таблицы MS SQL элементарнейшим запросом из которого можем твёрдо понять - какие именно таблицы локальной базы кэша нам необходимо обновить в данный момент.
Ну вот, вроде всё пояснил. Теперь ближе к теме.
Форум естественно читал. Как говорил выше - ну не гений я в SQL.
Вот например перл форумчанина iap
(Оффтоп: Мне вообще нравится его хозяйственная лаконичность. Ну что поделать, я не одарён языком Эзопа как и SQL вкупе, однако не унываю, и у меня найдётся немного положительных качеств...)

Товарищ iap

SQL
1
2
3
4
SELECT [Action]=CASE WHEN i.id IS NULL THEN 'delete' WHEN d.id IS NULL THEN 'insert' ELSE 'modify' END
,*
FROM deleted d FULL JOIN inserted i ON d.id=i.id
WHERE NOT EXISTS(SELECT d.* INTERSECT SELECT i.*);

Всё здесь отлично! Но не могу понять, с какой стороны мне к этому коду подойти, дабы трансформировать в рассказанное выше. А особенно "порадовало" Один из постов iap после которого ну, скажем так, очень хочется забиться в щель и не отсвечивать... Пока не подрастёшь...
Да не в этом суть. Суть в том, что нужна помощь. Есть у кого предложения - буду рад.

@invm · 13.10.2021, 20:15

Вы хотите выполнять запросы на сервере БД, а потом локально добавлять к их результатам значения из справочников?

@RafStudio · 13.10.2021, 23:26 **[ТС]**

НЕТ: смысл идеи заключается в том, чтобы получив от клиента запрос через Web API, собрать запрос к серверу SQL (если таковой вообще по итогу потребуется, поскольку многое можно будет выдать и из локального кэша) воспользоваться локальной БД в которой содержатся, в кэшированных таблицах, все основные МАЛОИЗМЕНЯЕМЫЕ справочники. Ну скажем: есть сервер отчётов. Дай Бог, если он меняется раз в 100 лет или к нему добавляется ещё один и раз в 200. Есть кассовые сервера. Они могут добавляться или изменяться раз в столетие или раз в месяц. Есть справочники категорий товаров - практически неизменяемые. Есть справочники брендов. Почти то же, что и с категориями товаров. И таких - множество. Один запрос может, допустим, иметь вид типа - а верни ка мне все идентификаторы справочников серверов к которым я могу обратиться через Ваше API и получив их, запросить идентификаторы категорий имеющихся товаров, для того, чтобы построить по ним выборку именно требуемых товаров. Вместо сложного, нагружающего SQL SERVER запроса, мы можем обратиться к нему используя все необходимые промежуточные данные из локальных таблиц. Ну это я так, пространно раскатал тему запроса. На деле - строю API доступа через основное приложение с привязкой к плагинам и максимально сниженной нагрузкой на SQL сервер данных путём кэширования малоподвижных в смысле изменения таблиц. Делаю это сугубо исходя из того, что предполагается существенная нагрузка на разного рода типовые запросы.
Так вот, таким образом мы формируем основную (по возможности) часть запроса из таблиц локальной базы данных, возможно выполняем некие простейшие арифметические операции, а уже к серверу SQL обращаемся по необходимости, в виду отсутствия оперативных данных из таблиц в принципе несуществующих в локальной БД.
Встаёт вопрос - как грамотно организовать кэш из серверных данных в локальных таблицах БД приложения?
Как вариант - в приложении организовать по таймеру запрос на сервер к ОДНОЙ таблице, хранящей информацию о изменениях в серверных таблицах имеющих отношение к кэшируемым на клиентской части. Подразумевается - если в контролируемой таблице (например КАТЕГОРИИ ТОВАРОВ) на сервере произошли любые изменения, по триггеру она должна изменить значение в таблице DataVersions в соответствующей строке, ответственной за данную таблицу, увеличив на +1 своё значение, если это int или изменив дату, если это datastamp. После чего из приложения опросив серверную таблицу DataVersions принять решение о необходимости обновления таблиц в БД локального кэша.
Опустим возможность распределения этой функции на два, три экземпляра приложения, с помощью которых мы можем балансировать нагрузку в принципе. Речь всё же о Web приложении, а точнее - Web API. Как по мне, таким образом можно весьма существенно снизить нагрузку на сервер SQL. И да, это не клиентское приложение. По сути это серверное приложение реализующее API доступа к информации из БД SQL сервера с возможностью кэширования заранее определённых таблиц.

Добавлено через 26 минут
Блин, как проще то объяснить? Ну вот так: Есть корневой SQL с малоподвижными таблицами (малоподвижные - высрал сам. Суть - малоизменяющиеся) Эти таблицы на сервере приложения (WEB API) есть ЗЕРКАЛА таблиц корневого SQL. Для чего? ПОТОМУ ЧТО ТАК МНЕ НУЖНО!
Моя просьба: помогите на SQL сервере в таблицу DataVersions в строке с именем таблицы (например t_table) установить флаг, что данные в таблице tbl_sysan изменились! Умоляю! Так, чтобы можно было в 10 утра субботнего вечера на сервере SQL проверить флаг таблицы tbl_sysan в таблице DataVersion и принять решение: зеркалировать её в локальный кэш прямо сейчас, или подождать до 24:00 утра понедельника...
Заранее спасибо...

И да, мне кажется, или я спятил - но решение в триггерах. В общем ничего не изменилось. Но, как говорил - с триггерами у меня просто вынос мозга. Видел кучу примеров типа: вот триггер на удаление, вот триггер на обновление, а вот - НА ИЗМЕНЕНИЕ!!! Но как это можно повторять, когда люди изящно пишут чуть ли не в одном запросе и то и другое и третье! Вот я о чём!

Добавлено через 34 минуты
Я выдержу, если iap разнесёт меня словами - слышь ты, молекула, что за говноод?!! Вот как надо было: xxx...xxx!!!
Креплюсь и думаю, что да - выстою. Но, я боюсь, что не выдержу другого - нет уже сегодня таких, каким был iap...
И вот беда - так ведь можно бросить программу, даже если до финала останется один байт, причём пешком...
Беда ведь, если некому помочь...

Добавлено через 28 минут
В двух словах (Вы спросили: "Вы хотите выполнять запросы на сервере БД, а потом локально добавлять к их результатам значения из справочников?") - и да и нет.
Много и сложно - есть разные справочники и все они синхронизируются по разному.
Говоря ДА, я подтверждаю - хочу выполнять запросы на сервере БД. Говоря НЕТ, я подтверждаю, что не собираюсь добавлять их к результатам значения или значений из справочников.
Итак: есть таблица tbl_sysan
Суть моей таблицы DataVersions - то же самое, что и rowversion только в масштабе конкретизации не строк, а всей таблицы, которая находится в списке DataVersions и для неё я желаю прописать триггер. Меня не интересует подробность изменения в контролируемой таблице в принципе. Было бы нужно, я бы конкретно вёл журнал изменений её данных. Интересует лишь - были ли изменения в ней или нет? Если да - по моей схеме, необходимо изменить некоторый флаг в таблице DataVersions для строки представляющей именно эту, изменившуюся таблицу. И да, я не про схему базы данных, а про конкретно - изменились ли данные в таблице tbl_sysan. Если ДА, то значит некий флаг, напротив строки с именем таблицы tbl_sysan, в столбце Version, должен измениться в таблице DataVersion, чтобы из своего приложения я увидел, что изменение имело место быть, а значит таблицу tbl_sysan я должен обновить в своём локальном кэше...

Добавлено через 9 минут
А вот таблицы tbl_pukan и tbl_sosan обновлять нет смысла - на сервере SQL для них ничего не изменилось, поскольку их триггер не отметил никаких изменений. Были бы - отобразились в DataVersions напротив своих имён...

Добавлено через 33 минуты
У Вас может возникнуть мысль - ну что за термояд?!! Ну пришёл запрос а у тебя справочники "дохлые", не обновлялись два дня или месяца - нет глобального интернет и что, какой ответ, тоже "дохлый" дашь? ОТВЕТ: синхронизация ведётся по GUID из справочников R-Keeper v7. А эти штуки никогда не меняются и могут только относиться к тому или иному бренду, категории, кассовому серверу и никогда и никак свой GUID не меняют. Нормальному человеку - ВСЁ СКАЗАНО! Так что проблема не там куда глядим! В остром случае - достаточно закрыть доступ по идентификаторам на любой кассе через локальное приложение. ВСЁ! Суть не в том! Суть в налаживании стабильной работы по синхронизации (зеркалированию) требуемых таблиц с сервера MS SQL в локальную базу. Требование - получить из запроса на MSQL сервер, типа:

SQL
1
SELECT * FROM [DATAVERSIONS]

информацию - какие таблицы локальной базы данных следует обновить. А это - ну видимо трудность...

@invm · 14.10.2021, 09:43

Сообщение от RafStudio

У Вас может возникнуть мысль - ну что за термояд?!! Ну пришёл запрос а у тебя справочники "дохлые", не обновлялись два дня или месяца - нет глобального интернет и что, какой ответ, тоже "дохлый" дашь? ОТВЕТ: синхронизация ведётся по GUID из справочников R-Keeper v7. А эти штуки никогда не меняются и могут только относиться к тому или иному бренду, категории, кассовому серверу и никогда и никак свой GUID не меняют. Нормальному человеку - ВСЁ СКАЗАНО!

Ну нормальные люди так же в курсе, что можно из метаданных получить дату последнего изменения данных в таблице.
Гуглите и узнаете как это сделать.

@RafStudio · 14.10.2021, 13:09 **[ТС]**

ОК. Спасибо за направление. Поизучал. В очередной раз много нового, но - это тоже не самый подходящий вариант. Самое главное - требуются далеко не юзерские права и всё, вариант отпал. Остальное, почему не айс, даже перечислять не буду...
Помимо всего прочего, я всё же не сидел сиднем и с удовольствием ознакомился со статьёй Джона Галлоуэй Зависимость кеша базы данных ASP.NET 1.1 (без триггеров)
Подход довольно интересный. Согласен - не подходит для таблиц с количеством записей более 600к, однако, как вариант - вполне себе ничего:

VB.NET
1
2
command = new SqlCommand("DECLARE @sum bigint;" &
"SELECT @sum = CHECKSUM_AGG(BINARY_CHECKSUM(*)) FROM t_table WITH (NOLOCK)")

По крайней мере пока вариант для клиентских запросов, а там глядишь, кто-то всё же поможет с написанием триггера...

Добавлено через 9 минут
С ошибками выше нацарапал но, кому надо поймут. Тем более что ссылка на статью с кодом есть.

@invm · 14.10.2021, 13:39

Сообщение от RafStudio

Самое главное - требуются далеко не юзерские права и всё, вариант отпал.

Все это решаемо, при желании.
Но, видимо, предпочитаете кривые, но такие простые и понятные решения...

А это для размышлений - https://coderoad.ru/14450415/П... ую-сумму-и

Успехов.

@RafStudio · 14.10.2021, 14:22 **[ТС]**

Не печальтесь, уважаемый! В тех таблицах, что будут кэшироваться, нет полей типа TEXT, NTEXT, IMAGE как и нет связанных с TIMESTAMP и DATETIME. Так что, в принципе проблема не такая уж и великая. Проблема, в которую Вы меня ткнули носом, мне была известна по ходу изучения Проверить наличие изменений в таблице SQL Server? Я принял аргументы к сведению.
И да, кто сказал, что самые простые варианты обязательно самые дерьмовые?
Однако, спасибо за терпение и мысли вслух.
Вам тоже не хворать.

@RafStudio · 23.10.2021, 02:31 **[ТС]**

В двух словах - (суть даже совсем не в принципе версионности datatable) суть в вопросе, который желаю задать именно Вам, поскольку вижу, не смотря на угрюмый вид и назидания с кафедры, у Вас ответ найдётся: Почему SQLite так интересно реагирует даже на T1, T2 и ORDER BY... Не, не буду тратить шанс подружиться - сам там разберусь с синонимами, если не сказать , что уже разобрался...
Щас, вопрос сформулирую...

Новые блоги и статьи Все статьи Все блоги /
Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .	Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .

@Andrey-MSK 3319 / 2206 / 387 Регистрация: 14.08.2018 Сообщений: 7,416 Записей в блоге: 4
	13.10.2021, 17:30
	RafStudio, А вам для чего? Если просто сохранить данные и не переписать более новые при редактировании, то используйте вот это: rowversion (Transact-SQL) 1

@invm 3614 / 2135 / 756 Регистрация: 02.06.2013 Сообщений: 5,169
	13.10.2021, 20:15
	Вы хотите выполнять запросы на сервере БД, а потом локально добавлять к их результатам значения из справочников? 0

@RafStudio 31 / 31 / 3 Регистрация: 08.08.2011 Сообщений: 195
	14.10.2021, 14:22 [ТС]
	Не печальтесь, уважаемый! В тех таблицах, что будут кэшироваться, нет полей типа TEXT, NTEXT, IMAGE как и нет связанных с TIMESTAMP и DATETIME. Так что, в принципе проблема не такая уж и великая. Проблема, в которую Вы меня ткнули носом, мне была известна по ходу изучения Проверить наличие изменений в таблице SQL Server? Я принял аргументы к сведению. И да, кто сказал, что самые простые варианты обязательно самые дерьмовые? Однако, спасибо за терпение и мысли вслух. Вам тоже не хворать. 0

@RafStudio 31 / 31 / 3 Регистрация: 08.08.2011 Сообщений: 195
	23.10.2021, 02:31 [ТС]
	В двух словах - (суть даже совсем не в принципе версионности datatable) суть в вопросе, который желаю задать именно Вам, поскольку вижу, не смотря на угрюмый вид и назидания с кафедры, у Вас ответ найдётся: Почему SQLite так интересно реагирует даже на T1, T2 и ORDER BY... Не, не буду тратить шанс подружиться - сам там разберусь с синонимами, если не сказать , что уже разобрался... Щас, вопрос сформулирую... 0