КаталогИндекс раздела


© IBM deweloperWork
© Е.Сандуленко, А.Деревянко (перевод)

Совместимы ли XML и реляционные базы данных?

Джордж Лапис, IBM

Реляционные базы данных являются доминирующими хранилищами данных, которые обеспечивают механизмы хранение и обработки данных, предлагающие эффективные методы и для хранения структурированных данных и для быстрого выполнения запросов. С другой стороны, XML - более новый, переносим_й формат данных, служащий для обмена полуструктурированными данными между несовместимыми системами или приложениями. Для бизнеса сегодня требуются и XML, и реляционные хранилища для легкого обмена данными и дополнительной гибкости. Когда имеет смысл комбинировать эти технологии? И какой лучший способ для реализации этого?

XML и базы данных

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

Что же такое XML база данных? Мы можем в общем случае различить базы данных с возможностями XML (XML-enabled) и базы данных с естественным XML (native XML). Мы называем базу данных XML-enabled, если ее модель ее ядра хранения и обработки данных - не XML модель данных. Во многих случаях ее ядро - реляционная модель и требуется отображение между моделью данных XML и реляционной моделью. Все ведущие реляционные системы баз данных могут рассматриваться, как XML-enabled базы данных, потому что они поддерживают такое отображение для управления данных XML. DB2 Universal Database V8 с DB2 XML Extender - типичный пример XML-enabled базы данных.

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

В частности, это определение допускает преобразование данных из модели данных XML в другие модели данных для их хранения и обработки. Это то, что мы определили для XML-enabled баз данных. Таким образом, требуется, чтобы native XML база данных также имела следующий два свойства:

Это краткое определение означает, что XML - уже не просто расширенный тип данных, это то, как данные обрабатываются, как логически, так и физически. Данные, представленые в XML, соответствуют физической схеме хранения на диске. Эта модель является лучшей для эффективного поиска XML-данных. Она также хорошо приспособлена для применения XML-схем. В последние годы появились различные native XML базы данных, обычно предлагаемые небольшими специализированными продавцами. В дополнение к XML-enabled базам данных и native XML базам данных мы также хотим ввести идею гибридной базы данных. Гибридная база данных - реляционная база данных, которая является XML-enabled базой данных, но в то же время предлагает и возможности native XML базы данных, описанные выше. Это база данных, которая поддерживает, и реляционную модель данных, и модель данных XML во всех ее механизмах обработки и хранения. Планируемый выпуск DB2 Universal Database - гибридная база данных.

Вопросы, которые поднимаются в этой статье: Какой тип базы данных является подходящим для ваших XML-данных? Как вы можете объединять XML и реляционное управление данными в одной системе?

Объединение XML и реляционных данных

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

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

Когда использовать XML, а когда использовать реляционный формат данных

У вас сейчас есть больше возможностей, чем когда-либо прежде, при выборе способа кодирования, хранения и выборки ваших данных. Рассмотрите и непосредственные, и долговременные последствия возможного выбора. В этом разделе мы исследуем преимущества и недостатки реляционной и XML моделей данных. Выделим несколько важных вопросов проектирования. Если вы начинаете с нуля, ваш первый вопрос может звучать так: "Должен я хранить мои данные в традиционной реляционной структуре или как XML?" Рассмотрите контрастирующие характеристики реляционных и XML моделей данных, показанные в таблице ниже.

Реляционная модель XML модель
Табличное представление. Иерархическое представление.
Строгая структура. К каждой строке таблицы применяется одна и та же схема. Статические определения схемы. Полуструктурированная. Гибкие определения схемы. XML-схема может существовать для всех или некоторых XML-документов. Схемы легко расширяемы.
Все отношения определены первичными ключами и внешними ключами. Документ содержит и данные, и информацию о связях.
Последовательность не имеет значения. Информация организована во множества, которые неупорядочены по определению. Последовательность имеет значение. Информация организована в последовательности, которые упорядочены по определению
Жестко типизирована. Каждая колонка имеет строго один тип данных Опционно типизирована. Типы могут быть определены для некоторых или для всех элементов и атрибутов в XML-схеме.
Стандартизация ANSI/ISO. Стандартизация W3C.
3-значная логика: true, false, null. 2-значная логика: true, false.
NULL Пустые элементы, отсутствующие элементы

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

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

Точно так для вас может быть лучшим хранение данных в XML, комбинируя их с реляционными данными, если для ваших данных истинно один или несколько следующих утверждений:

Выбор способа хранения базы данных для XML-данных

Если вы хотите комбинировать XML-данные с реляционными данными, вы должны рассмотреть следующие соображения проектирование. Прежде всего, как вы будете хранить и обращаться к XML-данным в выбранной вами реляционной или гибридной базе данных? Обычно у вас есть выбор: хранить XML-документы одним куском как текст в CLOB или VARCHAR колонке, или выполнять их декомпозицию и конвертировать XML в реляционный формат. Последний подход также называется нарезкой (shredding). В дополнение к этому гибридная база данных предлагает естественное хранение XML как третий вариант. В следующих разделах обсуждаются "за" и "против" каждого из этих трех способов, и затем проводится их сравнение.

Хранение XML как CLOB или VARCHAR

В реляционных базах данных вы можете хранить полные XML-документы в переменной символьного типа переменной длинны (VARCHAR) или как символьные большие объекты (CLOB). Если XML-документы вставлены в колонки CLOB или VARCHAR, они обычно вставляются как неразобранные текстовые объекты. Отказ от разбора XML экономит время и повышает производительность. Однако без разбора XML структура XML-документов полностью игнорируется. Это не позволяет базе данных выполнять интеллектуальный и эффективный поиск и операции извлечения под-документов из хранимого текста. Единственным способом является вызов XML-парсера во время выполнения запроса, чтобы <заглядывать внутрь> XML-документов, таким образом, условия поиска могут быть вычисляемыми. Таким образом, высокая производительность вставки достигается за счет низкой производительности поиска и выделения. Только тупая полная выборка документа, которая, опять-таки, игнорирует внутреннюю структуру XML, является быстрым способом чтения XML-документов из колонок CLOB или VARCHAR. Обновления отдельных элементов или атрибутов на уровне под-документов в XML-документах также требуют "дорогостоящего" разбора XML. Обратите внимание на то, что стоимость разбора для запросов выборки и обновления увеличивается пропорционально размеру XML-документов.

Во внутреннем представлении CLOB или VARCHAR удовлетворяют требованиям простоты и высокой производительности для вставки и выборки полного документа за счет слабого поиска, выделения и обновления.

Хранение в CLOB или VARCHAR могут быть выгодны для приложений, которые имеют один или более следующих свойств:

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

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

 <order date="2004-11-18">
 	<customer>Thompson</customer>
 	<part key="82"> .... </part>
 	<part key="83"> .... </part>
 	<orderinfo>
 				 ....
 	</orderinfo>
 </order>
  

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

Рис.1. XML-документы, хранимые как CLOB с побочными таблицами.

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

 SELECT order
 FROM mainTable, partSideTable
 WHERE mainTable.ID = partSideTable.ID
   AND partSideTable.part_key = 83;
  

Без побочной таблицы все документы заказов, у которых номер 83, должны читаться и разбираться. Для приложений с высокими требованиями к производительности это зачастую слишком накладно. В зависимости от СУБД, SQL запрос выглядит подобно такому:

 SELECT order
 FROM mainTable
 WHERE extract(order, '/order/part/@key') = 83;
  

Нарезка XML в реляционную схему

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

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

Рис.2. Нарезка и публикация XML-данных, в и из реляционной схемы

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

 <DEPARTMENT  deptid="15" deptname="Sales">
    <EMPLOYEE>
       <EMPNO>10</EMPNO>
       <FIRSTNAME>CHRISTINE</FIRSTNAME>
       <LASTNAME>SMITH</LASTNAME>
       <BIRTHDATE>1933-08-24</BIRTHDATE>
       <SALARY>52750.00</SALARY>
    </EMPLOYEE>
    <EMPLOYEE>
       <EMPNO>27</EMPNO>
       <FIRSTNAME>MICHAEL</FIRSTNAME>
       <LASTNAME>THOMPSON</LASTNAME>
       <BIRTHDATE>1948-02-02</BIRTHDATE>
       <SALARY>41250.00</SALARY>
    </EMPLOYEE>
 </DEPARTMENT>
  

Рис.3. XML-документ нарезается в две таблицы

После того, как данные нарезаны, вы можете использовать стандартные SQL/XML функции типа XMLELEMENT, XMLATTRIBUTES, XMLAGG и т.д для реконструирования XML-документа. Следующий оператор SQL/XML читает реляционные данные из таблиц Рис.3 и составляет тот же самый документ, который был нарезан в таблицы. Обратите внимание, что вложенность функций SQL/XML соответствует структуре документа. Первая функция XMLELEMENT создает элемент высшего уровня с названием DEPARTMENT, который содержит два атрибута и агрегацию элементов EMPLOYEE. Агрегация необходима, потому что в каждом отделе несколько служащих. Каждый элемент EMPLOYEE содержит множество (<лес>) элементов, которые хранят информацию, относящуюся к служащему. Функция XMLFOREST - просто это сокращение, чтобы мы не писали отдельную функцию XMLELEMENT для каждой колонки таблицы EMPLOYEE. Этот оператор SQL/XML выработает отдельный XML-документ для каждого отдела, один документ для каждой строки результата. Функция XML2CLOB, конвертирует построенное значение XML в CLOB, к которому может обращаться приложение. Альтернативой является новая стандартная функция SQL/XML XMLSERIALIZE, которая позволяет преобразовывать XML значения в CHAR или VARCHAR заданной длины.

  SELECT XML2CLOB(
      XMLELEMENT(NAME "DEPARTMENT", 
      XMLATTRIBUTES (d.deptid, d.deptname ),
      XMLAGG( XMLELEMENT(NAME "EMPLOYEE", 
                         XMLFOREST (e.empno, 
                                    e.firstname, 
                                    e.lastname, 
                                    e.birthdate, 
                                    e.salary) 
                        )
                  )
            ) 
      ) AS "deptdoc"
  FROM department d, employee e
  WHERE d.deptid = e.deptid
  GROUP BY  e.dept;
  

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

Например, представьте себе такое изменение схемы XML: показатель "max-occurrence" для элемента E изменен из 1 на больший, чем 1. Это означает, что реляционная колонка, которая хранит существующие значения для E, должна быть разбита на несколько таблиц. Более того, должны быть искусственно введены значения первичных ключей и внешних ключей, чтобы установить отношение 1-ко-многим между новой и старой таблицами. Это пугающе сложная задача, если таблица уже содержит большое количество данных. Таким образом, если данные уже введены, многие типы изменений в схеме неосуществимы. Это серьезно ограничивает гибкость, из-за которой обычно XML используется в первую очередь.

В дополнение к преобразовании схемы, подход нарезки может также требовать трансляции XPath или XQuery в SQL. Эта трансляция, как известно, является трудной, и результирующий SQL может быть неэффективен. Кроме того, сложные запросы XQuerie могут даже быть непереводимыми в SQL. Так что, нарезка наиболее приемлема, если используются только простые операции XPath или если приложения спроектированы для работы непосредственно с лежащей в основе реляционной схемой.

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

Хранение XML в типе данных native XML

Многие различные СУБД поддерживают тип данных XML, так что вы можете определять колонки типа XML, как показано в следующем операторе CREATE TABLE

 CREATE TABLE orders(orderkey INTEGER, order XML);
  

Документы могут быть вставлены в колонку XML, могут быть обновлены и найдены. Хотя СУБД может позволить вам управлять манипулировать данными в этой колонке как XML, из этого не обязательно следует, что она хранит и обрабатывает ваш XML-документ в естественном формате XML. За кулисами СУБД может преобразовывать XML-данные в реляционный тип, a Xpath преобразовывать в SQL. Это в основе то же самое, что и подход нарезки, который мы обсуждали выше. Или же тип XML может быть внутренне реализован как CLOB со всеми "за" и "против", которые уже обсуждались. Так что, внимательно читайте документацию СУБД, если она предоставляет поддержку "native XML". Она может быть не настолько "native", как может показаться.

Помните, что мы определили поддержку native XML как систему, которая обрабатывает и хранит XML-данные, используя модель данных XML. Это означает, что XML-документы хранятся и обрабатываются в разобранном (parsed) формате, таком, как XML Infoset или XQuery/Xpath Data Model. Он отличается от текстового представления XML в угловых скобках, он требует разбора XML, но не преобразования из модели данных XML в другие, реляционные структуры данных. Внутреннее представление является текстовым и не нарезается в реляционные или объектно-реляционные структуры. Внутреннее представление используется для обработки и хранения на диске, которое отражает иерархическую структуру XML-данных. В конце концов, XML - не только язык разметки, но также и иерархическая модель данных. Рис 4 показывает XML-документ и его иерархическое представление. Истинная СУБД с native XML использует деревья узлов как фундаментальную модель хранения и обработки.

Рис.4. XML-документ и его иерархическое представление

Как хранение native XML сопоставимо с хранением CLOB/VARCHAR? Разбор XML во время вставки ведет к несколько более низкой производительности, чем при хранении чистого CLOB без побочных таблиц. Аналогично полное извлечение документа из хранилища native XML требует сериализации (преобразования в последовательную форму), которое преобразовывает разобранный формат XML назад в его первоначальное текстовое представление. Опять-таки, это не может быть таким быстрым, как но чтение полного XML-документа из колонки CLOB/VARCHAR, которое не применяет сериализацию (потому что XML уже хранится в текстовом формате). Ключевое преимущество хранилища native XML состоит в том, что структура XML-документов явно представлена в базе данных. Таким образом, операции поиска, выделения и обновления не требуют разбора XML и могут быть выполнены с гораздо большей эффективность, чем при хранении CLOB. В основном, хранилище native XML жертвует производительностью операций вставки и обновления, чтобы получить более высокую производительность при выборке. Это - разумный компромисс для большинства приложений, потому что бизнес-данные чаще ищутся и анализируются, чем добавляются. В результате, большинство бизнес данных обычно имеет одно занесение и много запросов на выборку.

Как native XML хранение характеризуется по сравнению с нарезкой? Ключевое преимущество native XML по отношению к нарезке очевидно: Нет никакого преобразования между моделями данных. Структура и порядок XML-документа сохранены. Запросы XQuery и Xpath могут обрабатываться без перевода в SQL и без дополнительного разбора XML. Выражения XQueries и Xpath, которые часто бывают по природе своей навигационными, могут быть эффективно обработаны путем прохождения по дереву хранимого документа. Документы с XML-схемой и без нее могут храниться в колонке native XML, даже документы с изменяемыми и развивающимися схемами, без необходимости подгонки каких-либо сложных отображений. Выборка полных документов или фрагментов документа не требует, соединения многих таблиц. Хранение в native XML - единственный эффективный вариант, если XML-данные содержат сотни необязательных элементов и атрибутов, но каждый отдельный экземпляр содержит только часть их них. Для таких разреженных данных стоимость нормализации слишком велика, и денормализация непрактична из-за наличия ограничений на максимальную ширину строки и максимальное число колонок в таблице. Следовательно, есть потребность хранить и выполнять поиск в XML естественным образом, радом с другими реляционными данными.

В итоге хранилище native XML - хороший выбор для приложений, которые имеют один или более следующих свойств:

Хранение XML в естественном не препятствует их бесшовной интеграции с реляциоными данными в той же базе данных или даже в той же таблице. Язык SQL был расширен новыми функциями, такими как XMLQUERY, XMLEXISTS и XMLTABLE. Эти функции могут использоваться в операторах SQL для доступа к XML-данным и комбинирования их с реляционными данными.

Функция XMLTABLE создает виртуальную SQL таблицу, содержащую данные, которые происходят из XML-документов, хранящихся в базе данных XML. Это может использовано для предоставления приложению реляционного (табличного) представления XML-данных, хранимых в своем естественном формате. Так что, у вас нет необходимости нарезать XML в реляционные таблицы, чтобы ими могли воспользоваться реляционными приложениями, такие как инструменты генерации отчетов для интеллектуального ведения бизнеса. В качестве примера, давайте повторно рассмотрим документ отделов, который мы нарезали в две таблицы в предыдущем разделе (Рис 3). Здесь мы предполагаем, что тот же самый документ был вставлен в колонку XML "dept" таблицы "personnel". Следующий оператор SQL применяет функцию XMLTABLE к этой колонке XML, чтобы выработать реляционное представление данных, точно такое же, как в таблице на Рис 3

 SELECT DEPTID, EMPNO, FIRSTNAME, LASTNAME, BIRTHDATE, SALARY 
 FROM XMLTABLE ( '$dept/DEPARTMENT' 
       PASSING personnel.dept AS "dept" BY REF
       COLUMNS DEPTID    INTEGER PATH '@deptid
               EMPNO     INTEGER PATH 'EMPLOYEE/EMPNO', 
               FIRSTNAME VARCHAR(50) PATH 'EMPLOYEE/FIRSTNAME',  
               LASTNAME  VARCHAR(50) PATH 'EMPLOYEE/FIRSTNAME',  
               BIRTHDATE VARCHAR(50) PATH 'EMPLOYEE/FIRSTNAME',  
               SALARY    DECIMAL(8,2) PATH 'EMPLOYEE/SALARY' );
  

Резюме

Приведенная ниже таблица дает итог преимуществ и недостатков трех вариантов хранения XML, которые были рассмотрены в данной статье. Ни один из трех подходов не является единственным наилучшим вариантом для каждого приложения. Приложения с определенными характеристиками и требованиями могут находить, что хранение CLOB или нарезка - лучший вариант для них. Однако для большей части XML-приложений только хранение в native XML предлагает ту гибкость и производительность, которой они требуют. Кроме того, большинство бизнес-приложений имеет дело не только XML-данными. Они имеют существующие реляционные данные и продолжают вырабатывать реляционные данные. Неправильно утверждать: <или XML, или реляционная структура>, обычно правильно: <и XML, и реляционная структура>. XML-данные и реляционные данные должны обрабатываться интегрировано, и от СУБД требуется, чтобы они обеспечивали эффективную поддержку и для того, и для другого. Для многих приложений, наилучшим выбором будет гибридная реляционная и XML СУБД, которая объединяет действительно естественную поддержку XML со зрелой реляционной технологией баз данных. Таким образом, чтобы ответить на вопрос в заголовке этой статьи, XML и реляционные хранилища - не взаимоисключающие и не могут быть таковыми.

Свойство CLOB Нарезка Native
Гибкость схемы Наилучшая Плохая Наилучшая
Производительность поиска XML Плохая Хорошая Наилучшая
Производительность выборки полного документа Наилучшая Плохая Хорошая
Производительность выборки части документа Плохая Хорошая Наилучшая
Производительность вставки Наилучшая Плохая Хорошая
Производительность обновления (уровень под-документа) Плохая Хорошая Наилучшая
Управление параллельностью на уровне под-документа Плохая Хорошая Наилучшая
Удаление полного документа Наилучшая Плохая Хорошая
Сохранение структуры и порядка документа Наилучшая Плохая Наилучшая
Необходимость разбора XML при вставке Необязательная Да Да
Необходимость разбора XML при выборке Да Да Нет

КаталогИндекс раздела