Какой командой можно обновить материализованное представление

Данный пример, в частности, демонстрирует удобство использования представлений — без их использования указанное выше выражение с тремя join пришлось бы писать каждый раз. Также, если бы таблицы [math]Shops, Prices[/math] и [math]Items[/math] являлись бы результатом декомпозиции таблицы [math]ShopItem[/math] , создание данного представления позволяет избежать необходимости изменять код взаимодействия с ней.

Обновление представлений

Рассмотрим пример: в результате декомпозиции имевшейся таблицы [math]T[/math] получились таблицы [math]T_1[/math] и [math]T_2[/math] . Было создано представление [math]T[/math] , объединяющее результаты запроса из двух таблиц в тот вид, в котором данные присутствовали в изначальной.
Так же существует необходимость использовать не только операции чтения, но и записи, такие, чтобы:

• их результаты отражались [math]T_1[/math] и [math]T_2[/math] ;
• вставка была взаимообратна удалению;
• делать запись как если бы представление было таблицей;

Будем рассматривать обновления, как предварительное удаление (без проверки целостности) и последующую вставку обновленных данных.

Унарные операции

Фильтрация

Вставка кортежа в результат [math]R[/math] выполнения операции фильтрации [math]\sigma_(R)[/math] возможна только при выполнении им условия [math]P[/math] фильтра. В противном случае такая строка не окажется в результате, так как будет отфильтрована: она будет вставлена в базовую таблицу, но не появится в представлении.

Если кортеж удовлетворяет условию, данные можно как вставить, так и удалить.

Проекция

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

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

Переименование

Для выполнения вставки, происходит переименование атрибутов в исходном кортеже, после чего он вставляется.

При удалении соответствующий кортеж удаляется.

Множественные операции

Пересечение

Для пересечения [math]R_1 \cap R_2[/math] вставка кортежа выполняется как в [math]R_1[/math] , так и в [math]R_2[/math] . Так как предикатом пересечения является конъюнкция предикатов двух отношений, их проверка для кортежа не производится — в противном случае, кортеж не появится в ответе.

Аналогично, для удаления, кортеж должен быть удален из обоих отношений.

Объединение

Отсюда — алгоритм вставки для объединения [math]R_1 \cup R_2[/math] : для каждого из отношений проверить соответствие кортежа предикатам каждой из сторон; в случае удовлетворения, вставить в соответствующее отношение. Если кортеж удовлетворяет обоим предикатам, он должен появиться и слева, и справа

При удалении кортеж удаляется как из [math]R_1[/math] , так и из [math]R_2[/math] .

Разность

Для разности [math]R_1 \setminus R_2[/math] вставка производится в [math]R_1[/math] .

Удаление также производится из [math]R_1[/math] .

Соединения

При вставке кортежа в естественное соединение [math]R_1 \Join R_2[/math] часть его атрибутов, соответствующих [math]R_1[/math] , при удовлетворении предикату, вставляются в него, аналогично для [math]R_2[/math] .

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

Алгоритмы вставки и удаления базируются на ограничениях целостности:

• один-к-одному: вставка и удаление производятся как для левой, так и для правой части;
• один-ко-многим: кортеж вставляется в часть «многие», а в части «один» соответствующие данные уже могут присутствовать;
• многие-ко-многим: с точки зрения реальных баз данных, данное отношение преобразуется в join-table, имеющую отношение «один-ко-многим» с обеих из своих сторон;

Обновления и SQL

С точки зрения SQL:

• Унарные операции:
  • обновляемые;
  • необновляемые, несмотря на теоретическую возможность для обновления и пересечения и, с определенными ограничениями, для разности;
  • один-к-одному — обновляемые;
  • один-ко-многим — обновляемые только со стороны «многие»;
  • многие-ко-многим — необновляемые (там, где поддерживаются);

  Материализованные представления

  Определение:

  Материализованное представление — в отличие от представления, является «слепком» данных на определенный момент времени, который хранящимся физически в виде отдельной таблицы и не изменяется при изменении базовой версии.

  • быстрота выборки: материализованное представление может быть сформировано на основе сложного подзапроса, и, из-за того, что данные будут сохранены, этот запрос не будет пересчитываться повторно;
  • возможность «фиксации» данных;
  • для работы с актуальными данными, появляется необходимость обновления материализованное представление;
  • физически хранимые данные могут занимать большие объемы памяти;

  Синтаксис

  create materialized view имя [ refresh [fast|complete>] [on commit|demand>] [start with время] [next время] ] as запрос

  Некоторые БД поддерживают указание времени первого и последующих обновлений:

  [start with время] [next время]

  • fast : инкрементальные обновления в зависимости того, какие фрагменты данных были изменены в базовых таблицах этого отношения. Не рекомендуется использовать в условиях частого обновления исходной таблицы, для некоторых запросов данный режим может не поддерживаться;
  • complete : полный пересчет;
  • commit : при завершении любой операции;
  • demand : при вызове команды refresh materialized view ;

  refresh materialized view имя

  Пример

  Материализованное представление для подсчета текущих средних цен в магазинах, обновляемое раз в день:

  create materialized view AveragePrice refresh next dateadd(day, now(), 1) as select ShopId, avg(Price) from Prices group by ShopId

  См. также

  • Реляционная алгебра: унарные операции
  • Реляционная алгебра: операции над множествами
  • Реляционная алгебра: соединения, деление
  • Преобразование модели сущность-связь в физическую модель
  • Базы данных

  Литература

  1. https://www.kgeorgiy.info/courses/dbms/
  2. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильяме», 2005. — 1328 с.
  3. Gulutzan P., Pelzer T.(1999) SQL-99 complete, really. Gilroy,CA:CMP Books

  Какой командой можно обновить материализованное представление

  Материализованные представления в PostgreSQL основаны на системе правил, как и представления, но их содержимое сохраняется как таблица. Основное отличие между:

  CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM mytab;

  и этой командой:

  CREATE TABLE mymatview AS SELECT * FROM mytab;

  состоит в том, что материализованное представление впоследствии нельзя будет изменить непосредственно, а запрос, создающий материализованное представление, сохраняется точно так же, как запрос представления, и получить актуальные данные в материализованном представлении можно так:

  REFRESH MATERIALIZED VIEW mymatview;

  Информация о материализованном представлении в системных каталогах PostgreSQL ничем не отличается от информации о таблице или представлении. Поэтому для анализатора запроса материализованное представление является просто отношением, как таблица или представление. Когда запрос обращается к материализованному представлению, данные возвращаются непосредственно из него, как из таблицы; правило применяется, только чтобы его наполнить.

  Хотя обращение к данным в материализованном представлении часто выполняется гораздо быстрее, чем обращение к нижележащим таблицам напрямую или через представление, данные в нём не всегда актуальные (но иногда это вполне приемлемо). Рассмотрим таблицу с данными продаж:

  CREATE TABLE invoice ( invoice_no integer PRIMARY KEY, seller_no integer, -- идентификатор продавца invoice_date date, -- дата продажи invoice_amt numeric(13,2) -- сумма продажи );

  Если пользователям нужно быстро обработать исторические данные, возможно их интересуют только общие показатели, а полнота данных на текущий момент не важна:

  CREATE MATERIALIZED VIEW sales_summary AS SELECT seller_no, invoice_date, sum(invoice_amt)::numeric(13,2) as sales_amt FROM invoice WHERE invoice_date < CURRENT_DATE GROUP BY seller_no, invoice_date; CREATE UNIQUE INDEX sales_summary_seller ON sales_summary (seller_no, invoice_date);

  Это материализованное представление может быть полезно для построения графика в информационной панели менеджеров по продажам. Для ежесуточного обновления статистики можно запланировать задание по расписанию, которое будет выполнять этот оператор:

  REFRESH MATERIALIZED VIEW sales_summary;

  Ещё одно применение материализованного представления — предоставить быстрый доступ к данным, получаемым с удалённой системы через обёртку сторонних данных. Ниже приведён простой пример с обёрткой file_fdw , с замерами времени, но так как при этом использовался кеш локальной системы, выигрыш в производительности при обращении к удалённой системе обычно будет гораздо больше, чем показано здесь. Заметьте, что мы также использовали возможность добавить индекс в материализованное представление, тогда как file_fdw индексы не поддерживает; при других видах доступа к сторонним данным такого преимущества может не быть.

  CREATE EXTENSION file_fdw; CREATE SERVER local_file FOREIGN DATA WRAPPER file_fdw; CREATE FOREIGN TABLE words (word text NOT NULL) SERVER local_file OPTIONS (filename '/usr/share/dict/words'); CREATE MATERIALIZED VIEW wrd AS SELECT * FROM words; CREATE UNIQUE INDEX wrd_word ON wrd (word); CREATE EXTENSION pg_trgm; CREATE INDEX wrd_trgm ON wrd USING gist (word gist_trgm_ops); VACUUM ANALYZE wrd;

  Теперь давайте проверим написание слова. Сначала непосредственно через обёртку file_fdw :

  SELECT count(*) FROM words WHERE word = 'caterpiler'; count ------- 0 (1 row)

  Выполнив EXPLAIN ANALYZE , мы получаем:

  Aggregate (cost=21763.99..21764.00 rows=1 width=0) (actual time=188.180..188.181 rows=1 loops=1) -> Foreign Scan on words (cost=0.00..21761.41 rows=1032 width=0) (actual time=188.177..188.177 rows=0 loops=1) Filter: (word = 'caterpiler'::text) Rows Removed by Filter: 479829 Foreign File: /usr/share/dict/words Foreign File Size: 4953699 Planning time: 0.118 ms Execution time: 188.273 ms

  Если же теперь обратиться к материализованному представлению, запрос выполнится гораздо быстрее:

  Aggregate (cost=4.44..4.45 rows=1 width=0) (actual time=0.042..0.042 rows=1 loops=1) -> Index Only Scan using wrd_word on wrd (cost=0.42..4.44 rows=1 width=0) (actual time=0.039..0.039 rows=0 loops=1) Index Cond: (word = 'caterpiler'::text) Heap Fetches: 0 Planning time: 0.164 ms Execution time: 0.117 ms

  В любом случае слово записано неправильно, поэтому давайте попробуем найти то, что имелось в виду. Сначала опять через file_fdw и pg_trgm :

  SELECT word FROM words ORDER BY word 'caterpiler' LIMIT 10; word --------------- cater caterpillar Caterpillar caterpillars caterpillar's Caterpillar's caterer caterer's caters catered (10 rows)

  Limit (cost=11583.61..11583.64 rows=10 width=32) (actual time=1431.591..1431.594 rows=10 loops=1) -> Sort (cost=11583.61..11804.76 rows=88459 width=32) (actual time=1431.589..1431.591 rows=10 loops=1) Sort Key: ((word 'caterpiler'::text)) Sort Method: top-N heapsort Memory: 25kB -> Foreign Scan on words (cost=0.00..9672.05 rows=88459 width=32) (actual time=0.057..1286.455 rows=479829 loops=1) Foreign File: /usr/share/dict/words Foreign File Size: 4953699 Planning time: 0.128 ms Execution time: 1431.679 ms

  Затем через материализованное представление:

  Limit (cost=0.29..1.06 rows=10 width=10) (actual time=187.222..188.257 rows=10 loops=1) -> Index Scan using wrd_trgm on wrd (cost=0.29..37020.87 rows=479829 width=10) (actual time=187.219..188.252 rows=10 loops=1) Order By: (word 'caterpiler'::text) Planning time: 0.196 ms Execution time: 198.640 ms

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

  Пред.	Наверх	След.
  40.2. Система правил и представления	Начало	40.4. Правила для INSERT , UPDATE и DELETE

  CREATE MATERIALIZED VIEW AS SELECT (Transact-SQL)

  В этой статье описывается инструкция CREATE MATERIALIZED VIEW AS SELECT T-SQL в Azure Synapse Analytics для разработки решений. Здесь также приведены примеры кодов.

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

  Синтаксис

  CREATE MATERIALIZED VIEW [ schema_name. ] materialized_view_name WITH ( ) AS [;] ::= < DISTRIBUTION = HASH ( distribution_column_name ) | DISTRIBUTION = HASH ( [distribution_column_name [, . n]] ) | DISTRIBUTION = ROUND_ROBIN > ::= SELECT select_criteria 

  Этот синтаксис не поддерживается бессерверным пулом SQL в Azure Synapse Analytics.

  Аргументы

  schema_name

  Имя схемы, которой принадлежит представление.

  materialized_view_name

  Имя представления. Имена представлений должны соответствовать требованиям, предъявляемым к идентификаторам. Указывать имя владельца представления не обязательно.

  distribution option

  Поддерживаются только распределения HASH и ROUND_ROBIN. Дополнительные сведения о параметрах распространения см. в разделе CREATE TABLE: параметры распространения таблицы. Рекомендации по выбору распределения для таблицы на основе фактического использования или примеры запросов см. в статье Помощник по распространению в Azure Synapse SQL.

  DISTRIBUTION = HASH (distribution_column_name)
  Распределяет строки на основе значений одного столбца.

  DISTRIBUTION = HASH ( [distribution_column_name [, . n]] ) Распределяет строки на основе хэш-значений до восьми столбцов, что позволяет более равномерно распределять материализованные данные представления, уменьшая количество данных с течением времени и повышая производительность запросов.

  • Чтобы включить функцию распределения с несколькими столбцами, измените уровень совместимости базы данных на 50 с помощью этой команды. Дополнительные сведения о настройке уровня совместимости базы данных см. в разделе ALTER DATABASE SCOPED CONFIGURATION. Пример: ALTER DATABASE SCOPED CONFIGURATION SET DW_COMPATIBILITY_LEVEL = 50;
  • Чтобы отключить MCD, выполните эту команду, чтобы изменить уровень совместимости базы данных на AUTO. Например: ALTER DATABASE SCOPED CONFIGURATION SET DW_COMPATIBILITY_LEVEL = AUTO; существующие материализованные представления MCD останутся нечитаемыми.
    • Чтобы восстановить доступ к материализованным представлениям MCD, снова включите эту функцию.

    select_statement

    Список SELECT в определении материализованного представления должен соответствовать как минимум одному из следующих двух условий:

    • Список SELECT содержит агрегатную функцию.
    • В определении материализованного представления используется предложение GROUP BY, и все столбцы в предложении GROUP BY включены в список SELECT. В предложении GROUP BY можно использовать до 32 столбцов.

    В списке SELECT определения материализованного представления должны использоваться агрегатные функции. Поддерживаемые агрегаты: MAX, MIN, AVG, COUNT, COUNT_BIG, SUM, VAR, STDEV.

    Если в списке SELECT определения материализованного представления используются агрегаты MIN или MAX, применяются следующие требования:

    FOR_APPEND является обязательным. Например:

    CREATE MATERIALIZED VIEW mv_test2 WITH (distribution = hash(i_category_id), FOR_APPEND) AS SELECT MAX(i.i_rec_start_date) as max_i_rec_start_date, MIN(i.i_rec_end_date) as min_i_rec_end_date, i.i_item_sk, i.i_item_id, i.i_category_id FROM syntheticworkload.item i GROUP BY i.i_item_sk, i.i_item_id, i.i_category_id 

    Замечания

    Материализованное представление в хранилище данных Azure похоже на индексированное представление SQL Server. Оно имеет практически те же ограничения, что и индексированное представление (подробности см. в статье Создание индексированных представлений) за исключением того, что материализованное представление поддерживает агрегатные функции.

    Несмотря на то, что CREATE MATERIALIZED VIEW не поддерживает COUNT, DISTINCT, COUNT (выражение DISTINCT) и COUNT_BIG (выражение DISTINCT), запросы SELECT с этими функциями могут по-прежнему пользоваться преимуществами материализованных представлений для повышения производительности, так как оптимизатор Synapse SQL может автоматически перезаписывать эти агрегаты в пользовательском запросе для сопоставления с существующими материализованными представлениями. Дополнительные сведения см. в разделе с примером этой статьи.

    APPROX_COUNT_DISTINCT не поддерживается в CREATE MATERIALIZED VIEW AS SELECT.

    Материализованное представление поддерживает только кластеризованный индекс columnstore.

    Материализованное представление не может ссылаться на другие представления.

    Материализованные представления невозможно создать для таблицы с динамическим маскированием данных (DDM), даже если столбец DDM не является частью материализованного представления. Если столбец таблицы является частью активного или отключенного материализованного представления, DDM невозможно добавить в этот столбец.

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

    Материализованные представления можно создавать в секционированных таблицах. Операции SPLIT и MERGE для секций поддерживаются для базовых таблиц материализованных представлений. Переключение (SWITCH) секций не поддерживается.

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

    Сценарий	Новые столбцы, добавляемые к материализованному представлению	Комментарии
    COUNT_BIG() отсутствует в списке SELECT определения материализованного представления	COUNT_BIG (*)	Автоматически добавляется во время создания материализованного представления. Вмешательство пользователя не требуется.
    Пользователь указал функцию SUM(a) в списке SELECT определения материализованного представления, где "a" — это выражение, допускающее значение NULL	COUNT_BIG (a)	Пользователям необходимо добавить выражение "a" вручную в определении материализованного представления.
    Пользователь указал функцию AVG(a) в списке SELECT определения материализованного представления, где "a" — это выражение.	SUM(a), COUNT_BIG(a)	Автоматически добавляется во время создания материализованного представления. Вмешательство пользователя не требуется.
    Пользователь указал функцию STDEV(a) в списке SELECT определения материализованного представления, где "a" — это выражение.	SUM(a), COUNT_BIG(a), SUM(square(a))	Автоматически добавляется во время создания материализованного представления. Вмешательство пользователя не требуется.

    После создания материализованные представления отображаются в SQL Server Management Studio в папке представлений экземпляра Azure Synapse Analytics.

    Пользователи могут определить место, используемое материализованным представлением, с помощью инструкций SP_SPACEUSED и DBCC PDW_SHOWSPACEUSED. Существуют также динамические административные представления для предоставления более настраиваемых запросов для идентификации потребляемых пространства и строк. Дополнительные сведения см. в разделе Запросы размера таблицы.

    Материализованное представление можно удалить с помощью инструкции DROP VIEW. Отключить или перестроить материализованное представление можно с помощью инструкции ALTER MATERIALIZED VIEW.

    Материализованное представление — это автоматический механизм оптимизации запросов. Пользователям не требуется запрашивать материализованное представление напрямую. При отправке пользовательского запроса подсистема проверяет разрешения пользователя на объекты запроса и завершает запрос без выполнения, если у пользователя нет доступа к таблицам или обычным представлениям в запросе. Если разрешение пользователя подтверждено, оптимизатор автоматически использует для выполнения запроса соответствующее материализованное представление в целях повышения производительности. Пользователи получают одинаковые данные независимо от того, обрабатываются ли запросы путем обращения к базовым таблицам или материализованному представлению.

    План EXPLAIN и графический предполагаемый план выполнения в SQL Server Management Studio могут показать, считается ли материализованное представление оптимизатором запросов для выполнения запросов, а графический план предполагаемого выполнения в SQL Server Management Studio может показать, считается ли материализованное представление оптимизатором запросов для выполнения запроса.

    Чтобы узнать, поддерживает ли инструкция SQL новое материализованное представление, выполните команду EXPLAIN со свойством WITH_RECOMMENDATIONS . Дополнительные сведения см. в статье EXPLAIN (Transact-SQL).

    Тип собственности

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

    Разрешения

    Для создания материализованного представления пользователю, кроме соблюдения требований к владению объектами, нужны следующие разрешения.

    1. Разрешение CREATE VIEW в базе данных
    2. Разрешение SELECT на базовые таблицы материализованного представления
    3. Разрешение REFERENCES на схему, содержащую базовые таблицы
    4. Разрешение ALTER на схему, содержащую материализованное представление

    пример

    О. В этом примере показано, как оптимизатор Synapse SQL автоматически использует материализованные представления при выполнении запроса для лучшей производительности, даже если в запросе используются функции, которые не поддерживаются в CREATE MATERIALIZED VIEW, такие как COUNT(DISTINCT expression) . Запрос, который раньше выполнялся несколько секунд, теперь выполняется за долю секунды без каких-либо изменений в пользовательском запросе.

     -- Create a table with ~536 million rows create table t(a int not null, b int not null, c int not null) with (distribution=hash(a), clustered columnstore index); insert into t values(1,1,1); declare @p int =1; while (@P < 30) begin insert into t select a+1,b+2,c+3 from t; select @p +=1; end -- A SELECT query with COUNT_BIG (DISTINCT expression) took multiple seconds to complete and it reads data directly from the base table a. select a, count_big(distinct b) from t group by a; -- Create two materialized views, not using COUNT_BIG(DISTINCT expression). create materialized view V1 with(distribution=hash(a)) as select a, b from dbo.t group by a, b; -- Clear all cache. DBCC DROPCLEANBUFFERS; DBCC freeproccache; -- Check the estimated execution plan in SQL Server Management Studio. It shows the SELECT query is first step (GET operator) is to read data from the materialized view V1, not from base table a. select a, count_big(distinct b) from t group by a; -- Now execute this SELECT query. This time it took sub-second to complete because Synapse SQL engine automatically matches the query with materialized view V1 and uses it for faster query execution. There was no change in the user query. DECLARE @timerstart datetime2, @timerend datetime2; SET @timerstart = sysdatetime(); select a, count_big(distinct b) from t group by a; SET @timerend = sysdatetime() select DATEDIFF(ms,@timerstart,@timerend); 

    B. В этом примере пользователь User2 создает материализованное представление в таблицах, принадлежащих пользователю User1. Материализованное представление принадлежит пользователю User1.

    /**************************************************************** Setup: SchemaX owner = DBO SchemaX.T1 owner = User1 SchemaX.T2 owner = User1 SchemaY owner = User1 *****************************************************************/ CREATE USER User1 WITHOUT LOGIN ; CREATE USER User2 WITHOUT LOGIN ; GO CREATE SCHEMA SchemaX; GO CREATE SCHEMA SchemaY AUTHORIZATION User1; GO CREATE TABLE [SchemaX].[T1] ( [vendorID] [varchar](255) Not NULL, [totalAmount] [float] Not NULL, [puYear] [int] NULL ); CREATE TABLE [SchemaX].[T2] ( [vendorID] [varchar](255) Not NULL, [totalAmount] [float] Not NULL, [puYear] [int] NULL); GO ALTER AUTHORIZATION ON OBJECT::SchemaX.[T1] TO User1; ALTER AUTHORIZATION ON OBJECT::SchemaX.[T2] TO User1; /***************************************************************************** For user2 to create a MV in SchemaY on SchemaX.T1 and SchemaX.T2, user2 needs: 1. CREATE VIEW permission in the database 2. REFERENCES permission on the schema1 3. SELECT permission on base table T1, T2 4. ALTER permission on SchemaY ******************************************************************************/ GRANT CREATE VIEW to User2; GRANT REFERENCES ON SCHEMA::SchemaX to User2; GRANT SELECT ON OBJECT::SchemaX.T1 to User2; GRANT SELECT ON OBJECT::SchemaX.T2 to User2; GRANT ALTER ON SCHEMA::SchemaY to User2; GO EXECUTE AS USER = 'User2'; GO CREATE materialized VIEW [SchemaY].MV_by_User2 with(distribution=round_robin) as select A.vendorID, sum(A.totalamount) as S, Count_Big(*) as T from [SchemaX].[T1] A inner join [SchemaX].[T2] B on A.vendorID = B.vendorID group by A.vendorID ; GO revert; GO 

    См. также

    • ALTER MATERIALIZED VIEW (Transact-SQL)
    • DROP VIEW
    • EXPLAIN (Transact-SQL)
    • sys.pdw_materialized_view_column_distribution_properties (Transact-SQL)
    • sys.pdw_materialized_view_distribution_properties (Transact-SQL)
    • sys.pdw_materialized_view_mappings (Transact-SQL)
    • DBCC PDW_SHOWMATERIALIZEDVIEWOVERHEAD (Transact-SQL)
    • Представления каталога Azure Synapse Analytics и Analytics Platform System (PDW)
    • Системные представления, поддерживаемые в Azure Synapse Analytics
    • Инструкции T-SQL, поддерживаемые в Azure Synapse Analytics

    Далее

    Похожие публикации:

    1. Как определить количество строк в датафрейме
    2. Как удалить из 1с организацию
    3. Какой командой можно выполнить обновление конфигурации postgresql
    4. Колонки ловят радио как убрать