Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
BD_Otveti_po_liksiam.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
458.04 Кб
Скачать

Использование простого курсора и синтаксиса

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

DECLARE vend_cursor CURSOR

    FOR SELECT * FROM Purchasing.Vendor

OPEN vend_cursor

FETCH NEXT FROM vend_cursor;

  1. Индексы Transact-sql Индексы

SQL Server 2012

В следующей таблице приведен список типов индексов, доступных в SQL Server, а также указаны ссылки на дополнительные сведения.

Тип индекса

Описание

Дополнительные сведения

Кластеризованный

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

Описания кластеризованных и некластеризованных индексов

Создание кластеризованных индексов

Некластеризованный

Некластеризованный индекс можно определить в таблице или представлении вместе с кластеризованным индексом или в куче. Каждая строка некластеризованного индекса содержит некластеризованное ключевое значение и указатель на строку. Этот указатель определяет строку данных кластеризованного индекса или кучи, содержащую ключевое значение. Строки в индексе хранятся в порядке, определяемом значениями ключа индекса, но до создания кластеризованного индекса в таблице нет никакой гарантии того, что строки данных будут расположены в каком-либо определенном порядке.

Описания кластеризованных и некластеризованных индексов

Создание некластеризованных индексов

Уникальный

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

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

Создание уникальных индексов

Columnstore

Оптимизированный для памяти xVelocity индекс Columnstore, основанный на вертикальном секционировании данных, хранящихся по столбцам в виде больших объектов (LOB).

Индексы columnstore

Индекс с включенными столбцами

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

Создание индексов с включенными столбцами

Индекс на вычисляемых столбцах

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

Индексы вычисляемых столбцов

Фильтруемый

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

Создание отфильтрованных индексов

Пространственный

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

Общие сведения о пространственных индексах

XML

Вырезанное материализованное представление больших двоичных XML-объектов (BLOB) в столбце с типом данныхxml.

XML-индексы (SQL Server)

Полнотекстовое индексирование

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

Заполнение полнотекстовых индексов

XML-индексы (SQL Server)

SQL Server 2012

--3.Создать первичный и структурный индексы для XML-столбца.

CREATE PRIMARY XML INDEX idx_primary

ON Director (Dxml)

GO

CREATE XML INDEX idx_structural

ON Director (Dxml)

USING XML INDEX idx_primary FOR PATH

GO

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

  • Часто выполняются запросы XML-столбцов. При этом нужно учитывать расходы на сопровождение XML-индекса во время модификации данных.

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

XML-индексы разделяются на следующие категории.

  • Первичный XML-индекс

  • Вторичные XML-индексы.

Первым индексом, создаваемым для столбца типа данных xml, должен быть первичный XML-индекс. При наличии первичного XML-индекса поддерживаются вторичные индексы трех типов: PATH, VALUE и PROPERTY. Эти вторичные индексы могут способствовать повышению производительности выполнения разных типов запросов.

 Примечание

Создание или изменение XML-индекса невозможно до тех пор, пока параметры базы данных не будут соответствующим образом настроены для работы с типом данных xml. Дополнительные сведения см. в разделе Полнотекстовый поиск в XML-столбцах.

Экземпляры XML хранятся в столбцах типа данных xml в виде больших двоичных объектов (BLOB). Размер экземпляров типа xml бывает достаточно велик и в двоичном представлении может достигать 2 ГБ. При отсутствии индекса эти большие двоичные объекты разбираются на этапе выполнения запроса, что может занять некоторое время. Например, рассмотрим следующий запрос:

WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")

SELECT CatalogDescription.query('

/PD:ProductDescription/PD:Summary

') as Result

FROM Production.ProductModel

WHERE CatalogDescription.exist ('/PD:ProductDescription/@ProductModelID[.="19"]') = 1

Чтобы выбрать экземпляры XML, удовлетворяющие условию предложения WHERE, большой двоичный объект типа данных XML (объект BLOB) в каждой строке таблицыProduction.ProductModel разбирается во время выполнения запроса. Затем вычисляется выражение (/PD:ProductDescription/@ProductModelID[.="19"]) в методеexist(). В зависимости от размера и количества экземпляров, содержащихся в столбце, такой разбор на этапе выполнения запроса может потребовать значительных затрат.

Если приложение часто обращается к большим двоичным объектам XML (BLOB), индексирование столбцов типа xml поможет оптимизировать такие запросы. Однако поддержка индекса при изменении данных также связана с дополнительными затратами.

Первичный XML-индекс

При создании первичного XML-индекса индексируются все теги, значения и пути в экземплярах XML, хранимых в XML-столбце. Чтобы создать первичный XML-индекс, таблица, содержащая соответствующий XML-столбец, должна иметь кластеризованный индекс первичного ключа таблицы. При помощи первичного ключа в SQL Server строки первичного XML-индекса сопоставляются строкам таблицы, в которой содержится XML-столбец.

Первичный XML-индекс — это разобранное и сохраненное представление XML-объектов BLOB, содержащихся в столбце типа данных xml. Для каждого большого двоичного объекта (BLOB) столбца типа данных xml в индексе создается несколько строк данных, и их количество приблизительно равно числу узлов в большом двоичном объекте XML. Когда запрос получает полный экземпляр XML, SQL Server предоставляет экземпляр из XML-столбца. При обработке запросов в области экземпляров XML применяется первичный XML-индекс, и для возврата скалярных значений или поддеревьев XML может быть использован сам индекс.

В каждой строке для узла хранятся следующие сведения:

  • имя тега — элемента или атрибута;

  • значение узла;

  • тип узла: узел элемента, атрибута или текстовый узел;

  • сведения о положении в документе, представленные внутренним идентификатором узла;

  • путь от каждого узла до корня XML-дерева. По этому столбцу в запросе производится поиск выражений пути;

  • первичный ключ базовой таблицы. Дублируется в первичном XML-индексе для обратного соединения с базовой таблицей, а максимальное количество столбцов в первичном ключе базовой таблицы ограничено значением 15.

Перечисленные сведения об узле предназначены для вычисления и построения XML-результатов для указанного запроса. В целях оптимизации имя тега и данные о типе узла кодируются как целые значения, при этом в столбце Path используется такая же кодировка. Кроме того, пути сохраняются в обратном порядке, что позволяет сопоставлять их в тех случаях, когда известен только суффикс пути, Например:

  • //ContactRecord/PhoneNumber, где известны только два последних элемента

Or

  • /Book/*/Title, где в середине выражения указан символ-шаблон (*).

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

Например, следующий запрос возвращает сводные данные, содержащиеся в столбце CatalogDescription типа данных xml таблицы ProductModel. Запрос возвращает данные <Summary> только для тех изделий, описания каталога которых содержат также описание <Features>.

WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelDescription' AS "PD")SELECT CatalogDescription.query(' /PD:ProductDescription/PD:Summary') as ResultFROM Production.ProductModelWHERE CatalogDescription.exist ('/PD:ProductDescription/PD:Features') = 1

При использовании первичного XML-индекса вместо того, чтобы разбирать каждый экземпляр большого двоичного объекта типа данных XML в базовой таблице, методом exist() производится последовательный поиск заданного выражения в строках индекса, соответствующих данному объекту типа данных XML. Если в столбце Path индекса путь найден, элемент <Summary> вместе со своими поддеревьями извлекается из первичного XML-индекса и преобразуется в большой двоичный объект типа данных XML, возвращаясь в качестве результата метода query().

Обратите внимание, что при извлечении полного экземпляра XML первичный XML-индекс не используется. Например, следующий запрос извлекает из таблицы полный экземпляр XML, описывающий инструкции по изготовлению для определенного изделия.

USE AdventureWorks2012;SELECT InstructionsFROM Production.ProductModel WHERE ProductModelID=7;

Вторичные XML-индексы

Для повышения производительности поиска можно также создать вторичные XML-индексы. Перед созданием вторичных индексов должен существовать первичный XML-индекс. Существуют следующие типы вторичных индексов:

  • вторичный индекс PATH типа данных XML;

  • вторичный индекс VALUE типа данных XML;

  • вторичный индекс PROPERTY типа данных XML.

Ниже приведены некоторые рекомендации по созданию вторичных индексов.

  • Если при работе с XML-столбцами часто используются выражения пути, вторичный XML-индекс PATH, скорее всего, ускорит обработку данных. Типичный пример — выполнение метода exist() для XML-столбцов в предложении WHERE инструкции Transact-SQL.

  • Если с использованием выражений пути извлекаются множественные значения из отдельных экземпляров XML, может принести пользу кластеризация путей в пределах каждого экземпляра XML в индекс PROPERTY. Этот сценарий обычно имеет место при работе с наборами свойств, когда извлекаются свойства объекта и известно значение его первичного ключа.

  • Если запрашиваются значения экземпляров XML, не зная имен элементов или атрибутов, содержащих эти значения, следует подумать о создании индекса VALUE. Как правило, это имеет место при уточняющем запросе по осям нижних уровней (например, //author[last-name="Howard", где элементы <author> могут встречаться на любом уровне иерархии). Кроме того, такая ситуация встречается при обработке запросов с символами-шаблонами (например, /book [@* = "novel"], где в запросе выполняется поиск элементов <book>, имеющих некоторый атрибут со значением «novel»).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]