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

Возможность использования секционированных представлений была предусмотрена, начиная лишь с версии SQL Server 2000, но корпорацией Microsoft уже было указано, что в дальнейшем их применение не должно предусматриваться. В настоящей главе секционированные представления рассматриваются в связи с тем, что в течение нескольких лет они поддерживались корпорацией Microsoft в качестве одного из основных средств обеспечения высокой масштабируемости, поэтому читателю могут потребоваться знания о том, как действуют такие представления, если они когда-либо встретятся в устаревшем коде. С версии SQL Server 2005 секционированные представления заменяются секционированными таблицами.

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

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

Резюме

Практика показывает, что во многих базах данных представления применяются либо слишком широко, либо недостаточно полно. В частности, есть такие разработчики, которые, по-видимому, стремятся оформить в виде представлений весь код доступа к базе данных (не учитывая того, что в результате происходит переход на более высокий уровень абстракции и количество промежуточных этапов доступа к данным увеличивается). Встречаются и такие специалисты по базам данных, которые, по-видимому, вообще забывают о существовании таких средств обработки данных, как представления. Сам автор считает, что представления, как и все прочие программные средства, должны применяться исключительно исходя из того, насколько они подходят для решения конкретной задачи.

Основные области использования представлений перечислены ниже.

Выборка данных по критериям.

Защита конфиденциальных данных.

Уменьшение кажущейся сложности базы данных.

Создание дополнительного уровня доступа, благодаря которому несколько баз данных выглядят как одна база.

При использовании представлений необходимо учитывать ряд соображений.

Не рекомендуется создавать представления на основе других представлений. Вместо этого во вновь создаваемое представление необходимо включить соответствующую информацию запроса из исходного представления.

Следует помнить, что представления, в которых используется опция WITH CHECK OPTION, предоставляют определенные функциональные возможности, которые не могут быть реализованы с помощью обычного ограничения CHECK.

Представления, исходный код которых не должен становиться доступным для просмотра посторонними, могут быть зашифрованы. Решение о шифровании представлений обычно принимается с учетом того, имеет ли создаваемый программны!! продукт коммерческое назначение, или исходя из общих соображений обеспечения защиты информации.

Если для внесения изменений в представление используется оператор ALTER VIEW, то существующее представление полностью заменяется (хотя определенные ранее права доступа к представлению остаются неизменными). Из этого след}ет, что если требуется, чтобы в модифицированном представлении продолжали действовать заданные ранее опции кодирования и ограничения, то в оператор ALTER VIEW необходимо включить конструкции WITH ENCRYPTION и WITH CHECK OPTION.

Для отобракения кода, лежащего в основе представления, следует использовать системную процедуру sp helptext; для ознакомления с этим кодом не рекомендуется обращаться к системным таблицам.

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

В следующей главе приведены сведения об использовании пакетов и создании сценариев. Определенная информация по этой теме приведена и в данной главе в связи с описанием сценария с операторами INSERT, предназначенного для вставки строк в таблицу SalesOrderHeader, в котором информация из вновь вставленной строки затем использовалась для вставки данных в таблицу SalesOrderDetail. Пакеты и сценарии служат основой для создания хранимых процедур - программных объектов СУБД SQL Server, которые в наибольшей степени соответствуют определению собственных программ СУБД.

Глава 10

Сценарии и пакеты

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

Причем, что касается сценариев, то фактически их использует любой разработчик, выполняющий разные операции с помощью языка SQL. Каждый применяемый оператор CREATE, ALTER и SELECT представляет собой либо отдельный сценарий (если выполняется в единственном числе), либо часть сценария (если входит в состав нескольких операторов). Тем не менее сценарий, состоящий из одной короткой строки кода, как правило, не позволяет выполнрггь какие-либо достаточно содержательные действия, поскольку обычно вначале необходимо провести подготовку, затем выполнить требуемые операции, после чего обеспечить получение итоговых результатов.

Именно по этому принципу создаются сценарии SQL. А если в состав сценария, кроме операторов SQL, входят языковые элементы, поддерживаемые инфраструктурой .NET, то доступные возможности расширяются еще больше. Обычно сценарии предназначены для решения какой-то определенной задачи.

Другими словами, каждый оператор, входящий в состав сценария, направлен на достижение некоторой общей цели. При этом результаты вьшолнения одного оператора часто становятся предпосылкой успешного вьшолнения другого. В качестве примера можно назвать сценарии создания базы данных (которые часто используются при инсталляции системы), сценарии сопровождения системы (в частности, резервного копирования и восстановления), сценарии вызова утР1яит DBCC (Database Consistency Checker- программа проверки согласованности базы данных), т.е. сценарии, предназначенные для осуществления любых действий, обычно требующргх совместного применения нескольких операторов.

В настоящей главе рассматриваются не только сценарии, но и пакеты. Пакет представляет собой средство управления способом группирования операторов в СУБД SQL Server. Кроме того, в данной главе будет описана утилита SQLCMD с интерфейсом командной строки и показано, какое отношение она имеет к сценариям.