<row ContactID= l LastName= Achong FirstName= Gustavo SalesOrderID= 50756 OrderDate= 2003-06-01T00:00:00 />

<row ContactID= 2 LastName= Abel FirstName= Catherine SalesOrderID= 53459 OrderDate= 2003-09-01T00:00:00 />

<row ContactID= 2 LastName= Abel FirstName= Catherine SalesOrderID= 58907 OrderDate= 2003-12-01T00:00:00 />

<row ContactID= 2 LastName= Abel FirstName= Catherine SalesOrderID= 65157 OrderDate= 2004-03-01T00:00:00 />

<row ContactID= 2 LastName= Abel FirstName= Catherine SalesOrderID= 71782 OrderDate= 2004-06-01T00:00:00 />

Следует учитывать, что во время работы программы Management Studio происходит усечение значений любых полей, длина которых превышает величину, заданную в меню ToolsiOptions узла Results to Text в окне Query Results (этот максимум равен 8192). Такая проблема обнаруживается в окне результатов (при отображении в виде сетки или текста, хотя в сетке разрешен вывод более крупных чисел, если данные относятся к типу данных XML), а также при выводе данных непосредственно в файл. Причиной указанного нарушения в работе является само инструментальное средство, а не СУБД SQL Server. При использовании для выборки результатов другого метода (например, интерфейса ADO) подобная проблема не возникает.

Кроме того, следует учитывать, что символы перевода строки включены в приведенные выгие результаты только для удобства чтения, поскольку СУБД SQL Server просто выводит все элементы один за другим, чтобы уменьшить объем вывода.

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

Опция AUTO

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

Еще раз вернемся к примеру оформления заказов клиента, приведенному в последнем разделе. Но на этот раз воспользуемся опцией AUTO, чтобы узнать, в чем заключается отличие формируемого при этом вывода от довольно простого вывода, полученного с помощью опции RAW:

SELECT e.ContactID,

с.LastName,

с.FirstName,

soh.SalesOrderlD,

soh.OrderDate FROM Person.Contact с JOIN Sales.SalesOrderHeader soh

ON e.ContactID = soh.ContactID WHERE e.ContactID = 1 OR e.ContactID = 2 FOR XML AUTO

Первое очевидное отличие состоит в том, что теперь в качестве имени элемента применяется имя или псевдоним таблицы, которая является источником данных. Об этом следует помнить, выбирая псевдонимы для таблиц в запросе AUTO FOR XML. Но, возможно, еще более существенное отличие обнаруживается при более тщательном рассмотрении кода XML (автор и в этом случае немного откорректировал вывод, чтобы он стал более наглядным):

<с ContactID= l LastName= Aehong FirstName= Gustavo >

<soh SalesOrderID= 44132 OrderDate= 2001-09-01T00:00;00 /> <soh SalesOrderID= 45579 OrderDate= 2002-03-01T00:00:00 /> <soh SalesOrderID= 46389 OrderDate= 2002-06-01T00:00:00 /> <soh SalesOrderID= 47454 OrderDate= 2002-09-01T00:00:00 /> <soh SalesOrderID= 48395 OrderDate= 2002-12-01T00:00:00 /> <soh SalesOrderID= 49495 OrderDate= 2003-03-01T00:00:00 /> <soh SalesOrderID= 50756 OrderDate= 2003-06-01T00:00:00 />

</c>

<c ContactID= 2 LastName= Abel FirstName= Catherine >

<soh SalesOrderID= 53459 OrderDate= 2003-09-01T00:00:00 /> <soh SalesOrderID= 58907 OrderDate= 2003-12-01T00:00:00 /> <soh SalesOrderID= 65157 OrderDate= 2004-03-01T00:00;00 /> <soh SalesOrderID= 71782 OrderDate= 2004-06-01T00:00:00 />

</c>

Данные, источником которых является вторая таблица (в соответствии с тем, что указано в списке выборки), вкладываются в данные, источником которых является первая таблица. В этом случае происходит вложение элементов soh в элементы с. А если бы в списке выборки был в первую очередь приведен столбец из таблицы SalesOrderHeader, то элементы Contact были бы вложены в элементы SalesOrderHeader.

Указанная особенность, касающаяся правильного выбора последовательности расположения столбцов в списке выборки, заслуживает особого внимания! Чтобы понять, как следует поступать в каждом случае, достаточно подумать о том, какая основная задача должна быть решена с помощью запроса, включающего конструкцию FOR XML. Компоненты списка выборки следует упорядочивать таким образом, чтобы формируемая иерархическая структура документа XML соответствовала его назначению. Безусловно, если полученная иерархическая структура не отвечает вашим требованиям, ее всегда можно преобразовать в другую форму, но почему бы сразу же не обеспечить формирование с помощью СУБД SQL Server именно той структуры, которая требуется!

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

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

Опция EXPLICIT

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

Опция EXPLICIT позволяет определить каждый уровень иерархии и указать, как должен выглядеть каждый уровень. Для определения иерархии создается структура, которая имеет условное название универсальной таблицы. Универсальная таблица во многих отношениях полностью аналогична любому другому результирующему набору, который может быть сформирован в СУБД SQL Server. Обычно такая таблица формируется путем использования операторов UNION для соединения друг с другом данных, полностью представленных в виде одного уровня иерархии, но для выработки окончательного варианта кода XML можно также, например, формировать основной объем данных с помощью пользовательских функций, а затем применять к ним операторы SELECT. Основное различие между универсальной таблицей и более привычным результирующим набором (формируемым с помощью обычных запросов) заключается в том, что непосредственно в универсальной таблице должен быть предусмотрен достаточный объем метаданных, для того чтобы СУБД SQL Server могла преобразовать эту универсальную таблицу в документ XML, соответствующий требуемой схеме.

Но прежде чем переходить к дальнейшему описанию, необходимо пояснить, что подразумевается под выражением достаточный объем метаданных . Для этого рассмотрим реальную универсальную таблицу, позволяющую убедиться в том, насколько сложными могут оказаться такие метаданные. Эта таблица используется в примере кода, который рассматривается ниже в данном разделе (табл. 16.2).

Таблица 16.2. Типичный пример универсальной таблицы

Tag Parent с!11ContactID cIlILastName с 11!FirstName soh!2SalesOrderlD sohl2!OrderDate