Использование ключевого слова CONTENT при создании таблицы с столбцом XML из коллекции XML Schema
Создавая таблицу со столбцом типа XML, я имею в виду сложную сборку XML-схем . Когда я укажу схему XML , у меня есть возможность указать ключевое слово CONTENT или DOCUMENT . Последнее гарантирует, что данные XML будут храниться как документ в одном столбце.
Согласно видеоуроку, CONTENT сохранит XML-данные в фрагментах .
Помимо вышеприведенного утверждения, я не могу найти ссылки в другом месте относительно использования ключевого слова CONTENT и его последствий для схемы и данных.
Я хотел бы знать, как создавать и управлять фрагментами, и как и как их можно запросить индивидуально. Далее, как фрагменты коррелируют. Затем, когда я изменяю сборку XML Schema Collection, каково влияние.
на самом деле я думаю, что SQLServer 2005 XML довольно хорошо документирован.
CONTENT является стандартным и позволяет использовать любой допустимый XML. ДОКУМЕНТ является более конкретным и означает, что XML-данные, которые вы можете сохранить, разрешено иметь только один узел верхнего уровня.
Создайте:
CREATE TABLE XmlCatalog ( ID INT PRIMARY KEY, Document XML(CONTENT myCollection)) Вставка:
INSERT INTO XmlCatalog VALUES (2, '<doc id="123"> <sections> <section num="1"><title>XML Schema</title></section> <section num="3"><title>Benefits</title></section> <section num="4"><title>Features</title></section> </sections> </doc>')
Выбрать:
SELECT xCol.query('/doc[@id = 123]//section') FROM XmlCatalog WHERE xCol.exist ('/doc[@id = 123]') = 1
…и так далее. Язык запросов больше или меньше в подмножестве xpath 1.0.
Если вы изменяете XSD, он проверяется на вложениях и обновлениях и сохраняется в xml каждого элемента. Насколько я понимаю документ, также разрешено добавлять несколько схем для одного столбца, чтобы записи могли ссылаться на разные схемы.
РЕДАКТИРОВАТЬ:
Хорошо, прочитав отдельные части документации, я думаю, я понимаю, в чем проблема. Ссылка не очень ясна в этом пункте, но, насколько я понимаю, только записи с одним узлом верхнего уровня могут быть привязаны к схемам XSD.
В связи с тем, что для XSD-Schemas требуется один узел верхнего уровня, определяющий используемый XSD-файл, будет невозможно проверить фрагменты, содержащие более одного элемента верхнего уровня. Я не пробовал, но думаю, что это невозможно.
Однако представляется целесообразным определить столбец CONTENT, изменить XSD и сохранить оба XML с одним узлом верхнего уровня, ссылающимся на XSD, а также на XML-фрагменты, которые будут проверяться только на предмет корректности. Доступ к фрагментам можно получить с помощью отображения языка запросов XPath в вышеприведенном заявлении.
Я не могу рассказать вам о последствиях для работы. В ссылке упоминается, что XSD хранятся в строке, поэтому для этого потребуется дополнительное пространство внутри db. Запросы XPath также должны быть выполнены. Несмотря на то, что xpath обычно довольно быстро, я предполагаю, что он может уменьшить производительность, потому что он должен выполняться в каждой строке, чтобы получить результат. Чтобы убедиться, что вам нужно проверить план выполнения для вашего конкретного запроса в зависимости от размера и сложности хранимого xml, а также выражения xpath.