Секционированные таблицы и индексы SQL Server 2005 - Секционированные представления в SQL Server 7.0

Секционированные представления в SQL Server 7.0

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

На Рисунке 1, изображена схема представления YearlySales (годовой товарооборот). Вместо того чтобы размещать все продажи в одной-единственной большой таблице, Вы можете определить двенадцать отдельных таблиц, по одной на каждый месяц (SalesJanuary2003, SalesFebruary2003, и т.д.).

Пользователи, которые будут обращаться к представлению YearlySales со следующим ниже запросом, будут адресоваться ТОЛЬКО к таблице SalesJanuary2003.

SELECT ys.* 
  FROM dbo.YearlySales 
    AS ys
 WHERE ys.SalesDate = '20030113'

Пока ограничения целостности являются "доверительными" ("trusted"), и запросы к представлениям используют инструкцию WHERE для ограничения результатов выборок, основываясь на ключе секционирования (столбце, по которому определено ограничение целостности), до тех пор SQL Server будет обращаться только к необходимым базовым таблицам. "Доверительное" ограничение целостности - это ограничение целостности, для которого SQL Server в состоянии гарантировать, что все его данные придерживаются свойств, заданных ограничением целостности. По умолчанию, ограничение целостности создается с опцией WITH CHECK. Этот параметр вызывает блокировку схемы таблицы для того, чтобы данные могли быть сверены с ограничением целостности. Ограничение целостности будет добавлено, как только верификация проверит достоверность существующих данных; но если вдруг блокировка схемы будет удалена, последующие операторы INSERT, UPDATE и DELETE должны будут самостоятельно соблюдать ограничения целостности. Благодаря "доверительным" ограничениям целостности, разработчики могут значительно упростить создание представлений, поскольку им уже не нужно напрямую обращаться к интересующим их таблицам. Благодаря "доверительным" ограничениями целостности SQL Server улучшает производительность запросов, исключая ненужные таблицы из плана исполнения.

Примечание: ограничение целостности может стать "не доверяемым" ("untrusted") по нескольким причинам; например, если при выполнении оператора bulk-insert не задан аргумент CHECK_CONSTRAINTS. Как только ограничение целостности станет "не доверяемым", процессор запросов вернется к сканированию всех базовых таблиц, поскольку нет никакого способа подтвердить, что запрашиваемые данные действительно расположены в искомой таблице.