Відповіді:
Вони називаються індексованими поданнями в SQL Server - прочитайте ці технічні документи для отримання додаткової інформації:
В основному, все, що вам потрібно зробити, це:
і ви закінчили!
Хитра частина полягає в тому, що погляд повинен задовольняти безліч обмежень та обмежень - тих, що викладені в доповіді. Якщо ви зробите це - це все, що є. Представлення даних оновлюється автоматично, обслуговування не потрібне.
Додаткові ресурси:
Хоча суто з інженерної точки зору, проіндексовані подання звучать як щось, що кожен міг би використати для підвищення продуктивності, але реальний сценарій життя зовсім інший. Я невдало використовував індексовані подання там, де вони мені найбільше потрібні, через занадто багато обмежень щодо того, що можна індексувати, а що ні.
Якщо у представленнях є зовнішні з'єднання, їх не можна використовувати. Крім того, загальні вирази таблиці не дозволені ... Насправді, якщо у вас є впорядкування в підселектах або похідних таблицях (наприклад, з розділом за пунктом), вам теж не пощастить.
Це залишає лише дуже прості сценарії для використання індексованих поглядів, щось, на мій погляд, можна оптимізувати, створивши належні індекси в таблицях, що лежать в основі.
Мені буде приємно почути деякі сценарії реального життя, коли люди фактично використовували індексовані погляди на свою користь і не могли обійтися без них
(NOEXPAND)підказку до запитів, які використовують індексовані подання. І тоді ви помічаєте різницю. Перевага використання індексованих подань проти "правильної індексації таблиць" полягає в обмеженні вибору записів, інакше ви маєте рацію, це було б так само.
Можливо, вам знадобиться трохи більше інформації про те, що насправді є матеріалізованим видом. В Oracle це об’єкт, який складається з ряду елементів при спробі побудувати його в іншому місці.
MVIEW - це, по суті, знімок даних з іншого джерела. На відміну від подання, дані не знаходяться при запиті подання, вони зберігаються локально у вигляді таблиці. MVIEW оновлюється за допомогою фонової процедури, яка запускається через рівні проміжки часу або коли змінюються вихідні дані. Oracle дозволяє проводити повне або часткове оновлення.
У SQL Server я б використав наступне, щоб створити базовий MVIEW для регулярного (повного) оновлення.
По-перше, вид. Це повинно бути легко для більшості, оскільки подання досить часто зустрічаються в будь-якій базі даних далі, у таблиці. Це має бути ідентично поданню у стовпцях та даних. Це збереже знімок даних перегляду. Потім процедура, яка скорочує таблицю та перезавантажує її на основі поточних даних у поданні. Нарешті, робота, яка запускає процедуру, щоб розпочати свою роботу.
Все інше - експерименти.
Якщо індексований вигляд не є можливим, і швидкі оновлення не потрібні, ви можете створити таблицю кешованого злому:
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 transaction
NB: це з’їсть місце, також у ваших журналах TX. Найкраще використовувати для невеликих наборів даних, які повільно обчислюються. Можливо, рефакторинг для усунення "легких, але великих" стовпців спочатку у зовнішній вигляд.
Для MS T-SQL Server я пропоную розглянути можливість створення індексу з оператором "включити". Унікальність не потрібна, як і фізичне сортування даних, пов’язане з кластерним індексом. Функція "Індекс ... Включити ()" створює окреме фізичне сховище даних, яке автоматично підтримується системою. Він концептуально дуже схожий на Матеріалізований погляд Oracle.
https://msdn.microsoft.com/en-us/library/ms190806.aspx
https://technet.microsoft.com/en-us/library/ms189607(v=sql.105).aspx