Sql Server XML колонка лучшие практики

Question

Каковы оптимальные методы работы с XML-столбцами Sql-сервера для обеспечения быстрой производительности и удобства отчетности?

Как настроить столбец?Вы оставляете это как нетипизированный?или связать его со схемой?

Улучшает ли сопоставление столбца xml со схемой производительность запросов?

Мы используем следующие столбцы xml:

A.> Вкл.В расчете на одного клиента мы можем определить гибкое хранение их данных без перестройки нашей базы данных.

B.> Нам нужно создать представления отчетов для каждого клиента, которые возвращают свои данные, как если бы это была простая таблица (для отчетов Crystalили Sql Server Reporting Services).

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

SELECT 
Id, 
doc.value('@associatedId','nvarchar(40)') as AssocId,
doc.value('@name1', 'nvarchar(255)') as Name1,
doc.value('@name2', 'nvarchar(255)') as Name2,
doc.value('@name3', 'nvarchar(255)') as Name3,
doc.value('@number', 'nvarchar(255)') as Number
From OrderDetails
CROSS APPLY OrderDetails.XmlData.nodes('//root/reviewers/reviewer') as XmlTable(doc)

Есть ли более быстрый способ сделать это?этот запрос выполняется медленно для нас в таблице с 1 миллионом записей, но только 800 в настоящее время имеют данные XML!

Спасибо

Пит

Answer 1

Из Рекомендации XML для Microsoft SQL Server 2005 :

Использовать типизированный или нетипизированный XML?

Использовать нетипизированный тип данных XML под следующие условия:

• У вас нет схемы для ваших данных XML.
• У вас есть схемы, но вы не хотите, чтобы сервер проверял данные.

Это иногда тот случай, когда приложение выполняет на стороне клиента проверка перед сохранением данных в сервер, или временно хранит XML данные недействительны согласно схеме, или использует функции схемы XML не поддерживается на сервере (например, key / keyref).

Использовать типизированный тип данных XML под следующие условия:

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

Типизированные столбцы XML, параметры и переменные могут хранить документы XML или контент, который вы должны указать как флаг (ДОКУМЕНТ или СОДЕРЖАНИЕ, соответственно) во время декларация. Кроме того, вы должны предоставить одну или несколько схем XML. Укажите DOCUMENT, если каждый экземпляр XML имеет ровно один элемент верхнего уровня; в противном случае используйте CONTENT. Запрос компилятор использует флаг DOCUMENT в типе проверяет во время компиляции запроса выводить одноэлементные элементы верхнего уровня.

Связывает ли столбец xml со схемой производительность запросов? См. Пункт выше: используйте набрал XML, если вы хотите воспользоваться оптимизацией запросов на основе информации о типе.

Существует также длительное обсуждение преимуществ XML-индексов:

Ваше приложение может получить выгоду от индекса XML при следующих условиях:

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

И самое главное, соответствующий тип вторичного XML-индекса для вашего использования:

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

Answer 2

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

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

Существует 3 типа вторичных XML-индексов: PATH, VALUE и PROPERTY. Какие вторичные индексы вам нужны, зависит от типа запросов, которые вы собираетесь выполнять, поэтому я рекомендую вам просмотреть тему «Вторичные индексы XML» в Books Online, чтобы решить, какие из них будут вам полезны: http://msdn.microsoft.com/en-us/library/bb522562(SQL.100).aspx