|
Страница 2 из 19
Зачем базе данных XML Начнем с того, что XML предназначен для разметки данных, а лучшего места для хранения и обработки данных, чем база данных, трудно представить. Хранить документы XML в базе данных в принципе можно было с самого момента появления XML, но что касается обработки — тут все сложнее. Так как документы XML хранились в базе данных в виде объектов CLOB — Character Large Object, работать с ними на сервере именно как с документами XML было чрезвычайно сложно. Раз уж у нас нет возможности нормально работать с документами XML на сервере, давайте и не будем с ними работать как с документами XML вообще, а будем их преобразовывать к реляционному виду и сохранять в обычных таблицах. Такой метод существует и даже в определенных случаях является оптимальным, однако он плохо применим к неструктурированным или слабоструктурируемым документам XML. В том случае когда у нас есть четко формализованная модель документа XML, достаточно просто преобразовать ее к реляционному виду, однако когда заранее неизвестно, какой структуры будут документы XML, хранимые в базе данных, сделать это практически невозможно. Мне могут возразить, что данные с неопределенной структурой вообще не стоит обрабатывать на сервере. Это действительно так, и, если вам нужно просто хранить некие документы XML, неважно что содержащие, лучшего метода, чем CLOB, не найти. Но наиболее распространены случаи, когда модель документа XML описана лишь частично: документ может содержать различные элементы расширения, это могут быть документы новых версий данного формата с новыми элементами/атрибутами и т. д. На сервере могут появляться дополнительные хранимые процедуры (или могут изменяться существующие) для работы с новыми элементами документа XML, и здесь-то и возникает необходимость в наличии определенных механизмов работы с XML на сервере. В соответствии с требованиями времени, в SQL Server 2000 появилась функция openxml, которая позволяла преобразовывать строку в документ XML и представлять результат в виде таблицы. Однако данный метод имел определенные недостатки, связанные с простотой использования, производительностью и т. д., которые имели одно простое объяснение: XML — особый тип данных, имеющий собственные методы обработки (XPath), и не нужно пытаться эмулировать их с помощью реляционной алгебры. Поэтому в Yukon и появился новый встроенный тип XML, встроенный процессор языка XML, поддерживающий не просто XPath 1.0, а частично XPath 2.0 и XQuery. Теперь можно ответить на вопрос, какие именно преимущества вы получаете от использования типа XML в Yukon. - Возможность задействовать новый мощный язык запросов для XML — XQuery.
- Возможность индексировать поля типа XML.
- Возможность транзакционно изменять экземпляры типа XML
- Возможность проверять экземпляры типа XML на допустимость с помощью XML Schema
|