Автоматическая дельта-логика

#sql #sql-server

#sql #sql-сервер

Вопрос:

Предположим, у нас есть запрос Q1 (сохраненный как представление V1), результаты которого мы храним в таблице T1.

Мне было интересно, есть ли какой-либо способ предоставить автоматическую дельта-логику для T1. Это означает, что каждый раз, когда изменяется строка любого из источников данных Q1 (I / U / D), T1 изменяется таким образом, что базовый запрос является правильным.

Один из способов, которым я могу представить, что это возможно, — убедиться, что каждая строка T1 связана (с дополнительными столбцами или даже таблицами) с каждым ключом каждой таблицы, на которую опирается Q1. Затем установите в каждой из этих таблиц триггер, который отслеживает измененные ключи и rowversion. Затем, когда наступает время пересчета, (повторно) вычисляется набор строк T1, зависящих по крайней мере от одного измененного ключа.

Это достаточно сложно для конкретного запроса. Но как насчет создания автоматизированного способа? То есть создайте процедуру, которая принимает имя представления в качестве параметра и реализует это.

Я понимаю, что это звучит чрезвычайно сложно — по крайней мере, кажется, что мне понадобится полный анализатор SQL-сервера для вывода имен таблиц.

С другой стороны, я не могу быть единственным, кто подумал об этом. Дельта-логика очень полезна в таблицах с большим количеством операций чтения, чем записи, например, в таблицах транзакций.

Я предполагаю, что индексированные представления являются реализацией этого, но с ограниченной функциональностью (многие вещи не могут быть использованы, в первую очередь подзапросы).

Конечно, я бы не стал просить кого-то разработать что-то, чего не сделала MS…для меня. Итак, вопрос в том, доступна ли автоматическая дельта-логика?

Комментарии:

1. we have a query Q1 (stored as a view V1), the results of which we store at table T1. У вас логика наоборот. Запрос / представление является производным от таблицы

2. Запрос может быть сложным кодом, который считывается из любого количества таблиц. Я «сохранил» логику запроса в представлении и использую этот код для заполнения таблицы. Как и в, выберите * в T1 из V1. Дело в том, как сделать это умно….

3. ОК. это имеет больше смысла

4. Индексированное представление — это именно то, что вы описали, т. Е. База данных хранит копию данных и автоматически поддерживает / поддерживает их синхронизацию с источником. Вы правы, индексированные представления ограничены. Я не думаю, что есть что-то общее из коробки.

5. Большая проблема с такой общей задачей заключается в том, что она может создать значительную дополнительную нагрузку на сервер. Индексированные представления ограничены, поскольку это позволяет движку эффективно синхронизировать их с исходным кодом. Если запрос представления является сложным, вам придется повторно запускать сложный запрос полностью для каждого изменения в исходной таблице (таблицах). Это может быть очень дорого.