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

Вторичный индекс path типа данных xml

Если обычно запросы задают выражения пути для столбцов типа данных xml, вторичный индекс PATH может ускорить их поиск. Как ранее отмечалось, первичный индекс полезен в тех запросах, где метод exist() указан в предложении WHERE. Добавление вторичного индекса PATH может еще более повысить производительность поиска в таких запросах.

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

  • /root/Location, что задает только путь

Or

  • /root/Location/@LocationID[.="10"], где заданы как значение пути, так и значение узла.

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

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

В этом запросе в методе exist() выражение пути /PD:ProductDescription/@ProductModelID и значение "19" соответствуют ключевым полям индекса PATH. Это позволяет выполнять поиск непосредственно в индексе PATH и при этом обеспечивает более высокую производительность, чем при последовательном переборе значений пути в первичном индексе.

Вторичный индекс value типа данных xml

Если запрос основан на значении, например: /Root/ProductDescription/@*[. = "Mountain Bike"] или //ProductDescription[@Name = "Mountain Bike"], и если путь задан не полностью либо он включает в себя символ-шаблон, скорость выполнения запросов можно повысить, построив вторичный XML-индекс по значениям узлов первичного XML-индекса.

Ключевые столбцы индекса VALUE (значение узла и значение пути) содержатся в первичном XML-индексе. Индекс VALUE может оказаться полезным в тех случаях, если рабочая нагрузка включает в себя запросы значений из экземпляров XML, для которых неизвестны имена элементов или атрибутов, содержащих эти значения.Например, следующее выражение при наличии индекса VALUE выполняется более эффективно:

  • //author[LastName="someName"], где известно значение элемента <LastName>, но родительский элемент <author> может находиться где угодно;

  • /book[@* = "someValue"], где запрос выполняет поиск элемента <book> с каким-либо атрибутом, имеющим значение "someValue".

Следующий запрос возвращает столбец ContactID из таблицы Contact. Предложение WHERE задает фильтр, выполняющий поиск значений в столбцеAdditionalContactInfo типа xml. Идентификаторы контактов возвращаются только тогда, когда соответствующий большой двоичный объект XML, содержащий дополнительные контактные данные, включает в себя определенный номер телефона. Поскольку элемент <telephoneNumber> может находиться в любом месте XML-документа, выражение пути задает ось descendent-or-self.

WITH XMLNAMESPACES (

'http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ContactInfo' AS CI,

'http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ContactTypes' AS ACT)

SELECT ContactID

FROM Person.Contact

WHERE AdditionalContactInfo.exist('//ACT:telephoneNumber/ACT:number[.="111-111-1111"]') = 1

В этой ситуации искомое значение атрибута <number> известно, но оно может находиться в любом месте экземпляра XML как дочерний элемент элемента <telephoneNumber>. Производительность запроса такого рода может повыситься при поиске указанного значения по индексу.

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