Тип данных XML и столбцы (SQL Server)

Статья
04/26/2023

Применяется к:SQL Server Azure SQL Database Azure, управляемому экземпляру SQL Azure

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

Реляционная или XML-модель данных

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

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

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

Если ни одно из этих условий не выполняется, следует выбрать реляционную модель данных. Например, если данные представлены в формате XML, но приложение пользуется базой данных только для их хранения и извлечения, то для этого вполне подойдет тип данных [n]varchar(max) . Хранение данных в XML-столбце обеспечивает дополнительные преимущества. В их число входят проверка структуры и правильности данных, а также поддержка детализированных запросов и обновлений XML-данных.

Причины хранения XML-данных в SQL Server

Ниже приведены некоторые из причин использования собственных функций XML в SQL Server вместо управления xml-данными в файловой системе:

Требуется эффективно распространять, запрашивать и изменять свои XML-данные на основе транзакций. Большое значение имеет высокая детализация доступа к данным. Например, иногда нужно извлекать некоторые разделы XML-документа или вставлять в него новые разделы без замены всего документа.
Предстоит иметь дело с реляционными и XML-данными, и необходимо обеспечить их совместимость в приложении.
Необходима языковая поддержка запросов и модификации данных в приложениях, охватывающих несколько доменов.
Требуется, чтобы сервер гарантировал верность структуры данных и, возможно, проверял данные в соответствии с XML-схемами.
Требуется проиндексировать XML-данные для оптимизации обработки запросов и улучшения масштабируемости и использовать эффективный оптимизатор запросов.
Требуется обращаться к XML-данным, используя технологии SOAP, ADO.NET и OLE DB.
Требуется использовать для управления XML-данными средства администрирования, реализованные в сервере баз данных. Примерами таких задач управления могут служить резервное копирование данных, их восстановление и репликация.

Если же ни одно из этих условий не выполняется, то для хранения данных лучше использовать отличный от XML тип больших объектов (например, [n]varchar(max) или varbinary(max)).

Параметры хранилища XML

Ниже приведены варианты хранения XML в SQL Server:

Естественное хранение в виде типа xml

Данные при этом хранятся во внутреннем представлении, которое обеспечивает неизменность XML-содержимого данных. Это внутреннее представление включает в себя сведения об иерархии контейнеров, порядке документов и значений элементов и атрибутов. Точнее говоря, при этом обеспечивается неизменность InfoSet-содержимого XML-данных. Дополнительные сведения об информационном наборе см. в разделе http://www.w3.org/TR/xml-infoset. Содержимое InfoSet может не совпадать с копией текстового XML, так как следующие сведения не сохраняются: незначительные пробелы, порядок атрибутов, префиксы пространства имен и объявление XML.

Для типизированного (то есть связанного с XML -схемой) типа данных xml модуль проверки после обработки схемы (PSVI) добавляет в информационный набор данные о типах и кодирует их во внутреннее представление. Это значительно ускоряет синтаксический анализ. Дополнительные сведения см. в спецификациях XML-схемы W3C на страницах http://www.w3.org/TR/xmlschema-1 и http://www.w3.org/TR/xmlschema-2.
Сопоставление XML-данных и данных, хранящихся в реляционном формате

Используя аннотированную схему (AXSD), можно разбить XML на столбцы одной или нескольких таблиц. Это обеспечивает правильность данных на реляционном уровне. В результате гарантируется сохранность иерархической структуры данных, хотя порядок элементов не учитывается. Схема не может быть рекурсивной.
Хранение больших объектов, [n]varchar(max) и varbinary(max)

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

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

Выбор технологии XML

Выбор между естественным форматом XML и XML-представлениями обычно зависит от следующих факторов.

Варианты хранилищ

Иногда XML-данные (например, руководство по продукции) лучше хранить как большой объект, а в других ситуациях — в реляционных столбцах (например, описание товара, преобразованное в формат XML). Каждый вариант хранения данных обеспечивает точность документа в разной степени.
Обработка запросов

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

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

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

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

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

Собственное хранилище XML

XML-данные можно хранить на сервере в столбце типа xml . Этот вариант уместен, если выполняются следующие условия:

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

Механизм хранения XML-данных в естественном формате полезен, если есть XML-документы, имеющие разную структуру, или XML-документы, соответствующие разным или сложным схемам, которые слишком трудно сопоставить с реляционными структурами.

Пример. Модель XML-данных с помощью типа данных XML

Допустим, мы имеем дело с руководством по продукции в формате XML, которое охватывает ряд тем, разделенных на несколько глав, включающих по несколько разделов. Раздел может содержать подразделы. Таким образом, элемент <section> является рекурсивным. Руководства по продукции содержат большой объем смешанной информации, диаграмм и технических характеристик; эти данные структурированы частично. Пользователям руководств может пригодиться возможность контекстного поиска интересующих их тем, например подраздела «кластеризованный индекс» в разделе «индексирование», и запроса технических характеристик.

Для хранения таких XML-документов прекрасно подходит столбец типа xml . Это позволяет сохранить InfoSet-содержимое XML-данных. Индексирование XML-столбца позволяет повысить эффективность обработки запросов.

Пример. Сохранение точных копий XML-данных

Предположим, что правительственные законы требуют, чтобы хранились точные текстовые копии XML-документов. К этой категории могут относиться подписанные документы, юридические постановления и отчеты о биржевых операциях. Такие данные можно хранить в столбце типа [n]varchar(max) .

Для запроса преобразуйте данные в тип данных XML во время выполнения и выполните XQuery на нем. Преобразование типов в период выполнения может быть связано со значительной тратой ресурсов, особенно если документ велик. При высокой частоте запросов документы можно дополнительно сохранять в столбце типа xml и индексировать именно его, а для возврата точных копий документа использовать столбец [n]varchar(max) .

XML-столбец может быть столбцом, вычисляемым на основе столбца [n]varchar(max) . Однако вы не можете создать XML-индекс для вычисляемого столбца, XML-столбца и не может быть построен на столбцах [n]varchar(max) или varbinary(max).

Технология представления XML

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

Эта технология полезна в следующих ситуациях:

требуется реализовать ориентированную на XML модель программирования, используя XML-представления существующих реляционных данных;
есть XSD-схема или XDR-схема XML-данных, которую, возможно, предоставила внешняя партнерская организация;
Порядок не важен в данных, или данные таблицы запросов не рекурсивны, или максимальная глубина рекурсии известна заранее.
требуется запрашивать и изменять данные посредством XML-представления с использованием технологии XPath версии 1.0;
требуется выполнять массовую загрузку XML-данных и распределять их между базовыми таблицами с использованием XML-представления.

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

Пример: данные модели с помощью аннотированной XML-схемы (AXSD)

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

Гибридная модель

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

Значения, которые следует хранить в реляционных столбцах, зависят от рабочей нагрузки. Например, если вы извлекаете все XML-значения на основе выражения пути, /Customer/@CustIdто повышение значения CustId атрибута в реляционный столбец и индексирование может повысить производительность запросов. С другой стороны, если данные XML широко и нередундантно разложены на реляционные столбцы, то затраты повторной сборки могут быть значительными.

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

Детализация XML-данных

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

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

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

Ограничения типа данных XML

Обратите внимание, что на тип данных xml накладываются следующие ограничения:

Сохраненное представление экземпляров типов данных XML не может превышать 2 ГБ.
Его нельзя использовать в качестве подтипа экземпляра sql_variant .
Он не поддерживает приведение или преобразование в текст или ntext. Используйте вместо них varchar(max) или nvarchar(max) .
Его нельзя сравнить или отсортировать. Это означает, что тип данных XML нельзя использовать в инструкции GROUP BY.
Его нельзя использовать в качестве параметра для каких-либо скалярных встроенных функций, отличных от ISNULL, COALESCE и DATALENGTH.
Его нельзя использовать в качестве ключевого столбца в индексе. Однако может включаться в виде данных в кластеризованный индекс или явно добавляться в некластеризованный индекс при его создании с помощью ключевого слова INCLUDE.
XML-элементы можно вкладывать до 128 уровней.

См. также

Примеры массового импорта и экспорта XML-документов (SQL Server)