SQL Server 2008 - анализировать вручную XML или использовать встроенные индексы XML для поля XML?

Question

Я работаю над базой данных журналов в SQL Server 2008. Она будет состоять в основном из одной таблицы примерно так:

StepLog 
----------------
  StepLogID
  ClientID
  LogContent   XML
  CreateDate

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

Чтобы разрешить поиск в поле LogContent, текущий план заключается в программном уничтожении поля LogContent. Метаданные для измельчения должны быть в таблице примерно так:

XPathAttribute
----------------
  XPathAttributeID
  AttributeName
  AttributeDescription
  XPath

При вставке записи в StepLog у нас будет хранимая процедура, которая будет принимать все Xpath, определенные в XPathAttribute, и записывать их в другую таблицу, XPathAttributeValue

XPathAttributeValue
----------------
  XPathAttributeValueID
  StepLogID
  AttributeID
  AttributeValue 

Моя первоначальная идея, при рассмотрении этого проекта, заключалась в том, «почему бы просто не использовать XML-индексы, как первичные, так и вторичные?»

У меня нет большого опыта работы с XML-индексами, а у первоначального дизайнера был некоторый плохой опыт работы с XML-индексами (низкая производительность) в SQL Server2005, так возник этот дизайн.

Обратная связь будет очень признательна!

спасибо, Sylvia

Answer 1

XML-индексы помогают в определенных сценариях, как описано в Вторичные XML-индексы :

Ниже приведены некоторые рекомендации для создание одного или нескольких вторичных индексы:

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

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

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

В общем, я бы сказал ... измерить и посмотреть. Уничтожение XML и сохранение значений в реляционных таблицах с большой вероятностью повысит производительность по сравнению с необработанным доступом XML. Но это применимо, если вы знаете схему и уничтожаете конкретный набор информации, которую затем правильно индексируете. Прямо сейчас, даже если вы уничтожаете некоторую информацию, вы разбиваете ее на то, что по сути является структурой EAV, которую сложно запрашивать и оптимизировать. Я также рекомендую вам прочитать Рекомендации по моделированию семантических данных для повышения производительности и масштабируемости , чтобы узнать о недостатках EAV и о том, как избежать некоторых проблем.

Answer 2

Я в основном согласен с тем, что сказал @Remus.

То есть во всех отношениях использует встроенные XML-индексы.SQL Server замечательно хорошо справляется с огромными коллекциями XML (IMHO).Экономия времени по сравнению с вашим собственным будет неизмеримой.

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