Sql Server Xml Column Best Practices

Question

Каковы наилучшие методы работы с столбцами Xml-сервера Sql, чтобы обеспечить быструю производительность и простоту отчетности?

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

Связано ли столбец xml с улучшенной производительностью запросов?

Наше использование XML-столбцов выглядит следующим образом:

A.> На клиентской базе PER мы можем определить гибкое хранение своих данных, не перестраивая наш дб.

B.> Нам нужно создать представления отчетов для каждого клиента, который возвращает свои данные, как если бы это была простая таблица (для хрустальных отчетов или 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 Best Practices for Microsoft SQL Server 2005 От:

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

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

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

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

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

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

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

Связано ли столбец 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 необходимо сначала разбить blob в XML, а затем выполнять любые операции, которые вы запрашиваете. Основной XML-индекс хранит измельченный XML в базе данных, поэтому его не нужно делать «на лету». Сначала вам нужно создать первичный XML-индекс, а затем вторичные индексы XML могут быть созданы для поддержки ваших запросов.

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