Заключение

Поддержка XML и сопутствующих технологий в SQL Server 2005 значительно расширена, но все еще не достаточно соответствует стандартам. Какие выгоды получает разработчик от такого расширения поддержки XML? Можно ли полностью полагаться на SQL Server как на высокопроизводительный и надежный XML Server? Это сложные вопросы и в данный момент на них нет однозначного ответа.

SQL Server хранит XML-документ в бинарном, но последовательном (линейном) виде. XML-документ не представлен в виде дерева – в нем открывающие и закрывающие теги просто заменены определенными кодами. Возможно, для запросов такой формат удобен, но мы же знаем, что перед исполнением любого запроса XQuery, SQL Server сначала строит реляционную модель XML-документа и транслирует запрос XQuery в запрос SQL. Данная модель хранения абсолютно не оптимизирована для изменения документа, так как при вставках данных приходится передвигать все дочерние и последующие узлы. Можно возразить, что хранить XML-документ как дерево очень не эффективно, так как дерево занимает в несколько раз больший объем. Совершенно верно, но есть модели, где не нужно хранить указатели на все дочерние узлы элемента.

ПРИМЕЧАНИЕ XML-индекс занимает больший размер по сравнению с деревом в памяти (кроме того, что он еще и полностью дублирует информацию исходного документа).

Например, достаточно присвоить каждому узлу пару чисел (назовем их N и R) такую, что для всех прямых и косвенных дочерних узлов параметр N будет удовлетворять условию: Nparent > Ndescendant > R; а для всех последующих узлов параметр R будет удовлетворять условию: R > Nfollowing. В этом случае, узлы можно хранить обычным способом, как хранятся строки в РСУБД. Существуют и другие, более хитрые схемы [16, 17], но та, которая используется в SQL Server наиболее проста в реализации [12] и не оптимальна.

Скорость выполнения запросов XQuery пока также невелика по сравнению, например, с парсером XQuery из .NET Framework 2.0. Кроме того, что SQL Server-у необходимо преобразовать XML-данные в реляционную структуру, ему необходимо выбрать правильный план запроса. А как это возможно без статистики, я не представляю. Возможно, после построения индекса SQL Server начинает собирать определенную статистическую информацию, но это только догадки (вернее, пожелания). Почему разработчики не использовали тот же подход (или даже код), который используется в .NET Framework 2.0, где все запросы компилируются в MSIL, для меня также большая загадка.

Является ли SQL Server действительно подлинным XML database server? В [13] выдвигаются определенные требования к подобным серверам, среди которых:

• возможность работать с коллекциями документов (отсутствует в SQL Server)

• поддержка XML schema (присутствует в SQL Server)

• поддержка версионности (отсутствует)

• поддержка пространств имен (присутствует)

• индексирование (присутствует)

• авторизация доступа (отсутствует)

• поддержка изменений XML-документа (присутствует)

• представления XML-документа (xml views) (присутствует)

Часть из них SQL Server поддерживает, часть нет. Лично мое мнение такое: если к официальной версии разработчики исправят очевидные ляпы, повысят уровень соответствия последним стандартам и оптимизируют хранение XML-фрагментов и исполнение запросов – можно смело переносить все свои XML-приложения на SQL Server. В противном случае, SQL Server в качестве XML database server можно использовать только в очень узком диапазоне задач.