Создание индекса для представления с OpenQuery

Question

SQL Server не позволяет создавать представление с привязкой схемы, где запрос представления использует OpenQuery, как показано ниже.

Есть лиспособ или обходной путь для создания индекса для такого представления?

Answer 1

Лучшее, что вы можете сделать, - это запланировать периодический экспорт интересующих вас данных AD в таблицу.

Таблица, конечно, может иметь все индексы, которые вам нравятся. Если вы запускали экспорт каждые 10 минут, и возможность получения данных, которые устарели на 9 минут и 59 секунд, не является проблемой, тогда ваши запросы будут молниеносными.

Единственная часть проблемы будет связана с управлением блокировками и параллелизмом во время экспорта. Одна из стратегий может состоять в том, чтобы экспортировать данные в новую таблицу, а затем переименовать и заменить их. Другой может быть использование SYNONYMs (SQL 2005 и выше), чтобы сделать нечто подобное, когда вы просто указываете SYNONYM на две чередующиеся таблицы.

Данные, которые обеспечивают выполняемый вами запрос, поступают из совершенно другой системы за пределами SQL Server. SQL Server не может создать индексированное представление для данных, которые ему не принадлежат. Для начала, как он будет уведомлен, когда что-то было изменено, чтобы он мог обновить свои индексы? Должен существовать некоторый механизм уведомлений и обновлений, что неправдоподобно, поскольку SQL Server не может разумно поддерживать ACID для такой распределенной, медленной, не SQL-транзакции сервера во внешнюю систему.

Таким образом, мое предложение подражать таким вещам через ваши собственные запланированные задания, которые обновляют данные каждые X минут.

- Ответ на ваш комментарий -

Невозможно определить, был ли добавлен новый пользователь, без запроса. Если Active Directory поддерживает какой-то API, который генерирует события, я никогда не слышал об этом.

Но каждый раз, когда вы запрашиваете, вы можете хранить наибольшее время создания всех пользователей в таблице, а затем с помощью динамического SQL запрашивать только новых пользователей с датой создания после этого. Этот запрос теоретически должен быть очень быстрым, поскольку он будет передавать очень мало данных по проводам. Вам просто нужно посмотреть, каким будет точное поле AD для даты создания пользователя и синтаксис условий для этого поля.

Если управление динамическим SQL было слишком сложным, очень простое приложение vbscript, VB или .Net также могло бы запросить у вас активный каталог по расписанию и обновить базу данных.

Answer 2

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

Этот список из http://www.sqlteam.com/article/indexed-views-in-sql-server-2000

1. Определение представления всегда должно возвращать одинаковые результаты из одних и тех же базовых данных.

2.Просмотры не могут использовать недетерминированные функции.

3. Первый индекс в представлении должен быть кластеризованным, УНИКАЛЬНЫМ индексом.

4.Если вы используете Group By, вы должны включить новый COUNT_BIG (*) в список выбора.

5. Определение определения не может содержать следующее

a.TOP

b.Text, ntext or image columns

c.DISTINCT

d.MIN, MAX, COUNT, STDEV, VARIANCE, AVG

e.SUM on a nullable expression

f.A derived table

g.Rowset function

h.Another view

i.UNION

j.Subqueries, outer joins, self joins

k.Full-text predicates like CONTAIN or FREETEXT

l.COMPUTE or COMPUTE BY

m.Cannot include order by in view definition

Answer 3

В этом случае SQL Server не может узнать о каких-либо изменениях (данных, схемы и т. Д.) В удаленном источнике данных. Для локальной таблицы он может использовать SCHEMABINDING и т. Д., Чтобы убедиться, что базовые таблицы остаются прежними, и он может отслеживать изменения данных.

Если вам нужно часто запрашивать представление, я бы использовал локальную таблицу, которая периодически обновляется. На самом деле, я бы все равно использовал стол. AD запросы не самые быстрые в лучшие времена ...