Я собираюсь разработать DW и слышал о материализованных представлениях. На самом деле я хочу создать представление, и оно должно автоматически обновляться при изменении базовых таблиц. Может ли кто-нибудь объяснить на примере запроса ..
Ответы:
В SQL Server они называются индексированными представлениями - прочтите эти официальные документы, чтобы узнать больше:
По сути, все, что вам нужно сделать, это:
и вы сделали!
Сложность заключается в том, что представление должно удовлетворять целому ряду ограничений и ограничений - они изложены в официальном документе. Если так сделаешь - все, что есть. Представление обновляется автоматически, обслуживание не требуется.
Дополнительные ресурсы:
Хотя чисто с инженерной точки зрения, индексированные представления кажутся чем-то вроде того, что может использовать каждый для повышения производительности, но реальный сценарий сильно отличается. Мне не удалось использовать индексированные представления там, где они мне больше всего нужны, из-за слишком многих ограничений на то, что можно индексировать, а что нет.
Если у вас есть внешние соединения в представлениях, их нельзя использовать. Кроме того, общие табличные выражения не допускаются ... Фактически, если у вас есть какой-либо порядок в подзапросах или производных таблицах (например, с разделением по предложению), вам тоже не повезло.
Это оставляет только очень простые сценарии для использования индексированных представлений, что, на мой взгляд, можно оптимизировать, в любом случае создав соответствующие индексы для базовых таблиц.
Я буду рад услышать несколько реальных жизненных сценариев, в которых люди действительно использовали индексированные просмотры в своих интересах и не смогли бы обойтись без них.
(NOEXPAND)подсказку к запросам, которые используют индексированные представления. И тогда вы замечаете разницу. Преимущество использования индексированных представлений по сравнению с «правильной индексацией таблиц» заключается в ограничении выбора записей, иначе вы правы, это будет то же самое.
Возможно, вам понадобится немного больше информации о том, что на самом деле представляет собой материализованное представление. В Oracle это объект, который состоит из ряда элементов, когда вы пытаетесь построить его где-то еще.
MVIEW - это, по сути, снимок данных из другого источника. В отличие от представления данные не обнаруживаются, когда вы запрашиваете представление, они хранятся локально в виде таблицы. MVIEW обновляется с помощью фоновой процедуры, которая запускается через регулярные промежутки времени или при изменении исходных данных. Oracle допускает полное или частичное обновление.
В SQL Server я бы использовал следующее, чтобы создать базовый MVIEW для регулярного (полного) обновления.
Во-первых, взгляд. Это должно быть легко для большинства, поскольку представления довольно часто встречаются в любой базе данных Next, таблице. Это должно быть идентично представлению в столбцах и данных. Это будет хранить снимок данных просмотра. Затем процедура, которая усекает таблицу и перезагружает ее на основе текущих данных в представлении. Наконец, задание, которое запускает процедуру для начала своей работы.
Все остальное - эксперименты.
Когда индексированное представление недоступно и быстрые обновления не требуются, вы можете создать таблицу кеширования взлома:
select * into cachetablename from myviewname
alter table cachetablename add primary key (columns)
-- OR alter table cachetablename add rid bigint identity primary key
create index...затем sp_rename view / table или измените любые запросы или другие представления, которые ссылаются на него, чтобы они указывали на таблицу кеша.
расписание ежедневно / ночью / еженедельно / еще много чего обновлять
begin transaction
truncate table cachetablename
insert into cachetablename select * from viewname
commit transactionNB: это будет занимать место, также в ваших журналах tx. Лучше всего использовать для небольших наборов данных, которые медленно вычисляются. Может быть, провести рефакторинг, чтобы сначала исключить "простые, но большие" столбцы во внешний вид.
Для MS T-SQL Server я предлагаю изучить создание индекса с помощью оператора include. Не требуется ни уникальности, ни физической сортировки данных, связанных с кластеризованным индексом. «Индекс ... Include ()» создает отдельное физическое хранилище данных, автоматически поддерживаемое системой. Концептуально это очень похоже на материализованное представление Oracle.
https://msdn.microsoft.com/en-us/library/ms190806.aspx
https://technet.microsoft.com/en-us/library/ms189607(v=sql.105).aspx