Программирование баз данных. Программирование

Программирование >> Программирование баз данных

1 ... 196 197 198 [ 199 ] 200 201 202 ... 346

Это - более сложная рекомендация, чем могло бы показаться на первый взгляд. В своих рекомендациях корпорация Microsoft исходит из того, что опция PATH обеспечивает создание более простого кода. Безусловно, опция PATH позволяет создавать программные конструкции, более простые в некоторых отношениях, но, как будет показано в данном разделе, при ее применении приходится сталкиваться с такими многочисленными исключениями, что в конечном итоге становится нелегко понять, каким должен быть окончательный вариант запроса. Дело в том, что для успешного использования опции PATH необходимо знать язык XPath, а если разработчик не обладает такими знаниями, то для него фактически во многих случаях более простой в применении становится опция EXPLICIT. Тем не менее специалисты, использующие в своей работе язык XML, так или иначе обязаны освоить язык XPath, а после успешного его освоения обнаруживается, что подход, основанный на применении опции PATH, который базируется на знании языка XPath, является более удобным.

Однако следует учитывать, что если в разрабатываемом приложении должна обеспечиваться обратная совместимость с программным обеспечением версии SQL Seruer 2000, то допускается применение только опции EXPLICIT.

Несмотря на сказанное выше, в наиболее простых вариантах ее использования опция PATH является не такой уж сложной. Поэтому вначале рассмотрим, какие основные требования связаны с применением опции PATH. Затем перейдем к рассмотрению более сложных примеров, которые позволяют продемонстрировать некоторые нетривиальные возможности опции PATH.

Общее описание условий использования опции path

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

Способы формирования ссылок на конкретные данные с помощью опции PATH регламентируются несколькими правилами, в которых, в частности, учитывается то, является ли столбец с данными именованным или неименованным (как и при использовании опции EXPLICIT, если задан псевдоним, то именем считается этот псевдоним). Если столбец имеет имя, то применяется еще несколько дополнительных правил в зависимости от обстоятельств.

В следующих разделах рассматриваются некоторые варианты применения опции PATH.

Неименованные столбцы

Данные, находящиеся в тех столбцах результирующего набора, которым не присвоены имена, рассматриваются в элементе row как бесформатный текст. В качестве примера использования неименованных столбцов рассмотрим модифицированную версию запроса, который применялся для иллюстрации конструкции FOR XML RAW.

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

SELECT e.ContactID,

COUNT(soh.SalesOrderlD) FROM Person.Contact с JOIN Sales.SalesOrderHeader soh

ON e.ContactID = soh.ContactID WHERE e.ContactID = 1 OR e.ContactID = 2 GROUP BY e.ContactID FOR XML PATH

Рассмотрим полученные результаты:

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

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

Мне неловко повторять одно и то же бесконечное количество раз, но я обязан снова напомнить, что точные числовые значения (в данном случае число 7), полученные в конкретной системе, зависят от того, много ли было проведено экспериментов с данными таблицы. В этом случае важно не то, какие именно числовые данные формируются в сочетании с элементом ContactID, а то, что в элементе raw создается бесформатный текст.

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

Именованные столбцы

Усложнение используемых программных конструкций происходит значительно быстрее именно после перехода к применению именованных столбцов. В своей наиболее простой форме именованные столбцы применяются почти так же просто, как неименованные. И действительно, один из подобных вариантов использования именованного столбца был показан в предьщущем примере. Дело в том, что если некоторый столбец, имеющий имя, обозначается с помощью опции PATH, то происходит всего лишь добавление в элемент row дополнительного элемента, соответствующего этому столбцу: <row><ContactID>l</ContactID>7</row>

В данном случае столбец ContactID представляет собой простой именованный столбец.

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

Символ @

Данный раздел посвящен описанию символа @. Если к имени столбца добавляется символ @, то этот столбец рассматривается в СУБД SQL Server как атрибут предьщущего столбца. Преобразуем структуру формируемого фрагмента XML так, чтобы данные столбца ContactID бьши представлены в виде атрибута элемента верхнего уровня, содержащего данные строки:

SELECT e.ContactID AS ©ContactID,

COUNT(soh.SalesOrderlD) FROM Person.Contact с JOIN Sales.SalesOrderHeader soh

ON e.ContactID = soh.ContactID WHERE e.ContactID = 1 OR e.ContactID = 2 GROUP BY e.ContactID FOR XML PATH

В результате формируется следующий вывод:

Обратите внимание на то, что данные о количестве заказов по-прежнему представлены в виде текстового информационного наполнения элемента row, а в состав самого элемента вошли в виде атрибута только данные указанного столбца. Такое преобразование можно продолжить, присвоив имя столбцу с данными о количестве заказов и также обозначив его имя префиксом для преобразования в атрибут:

ON e.ContactID = soh.ContactID WHERE e.ContactID = 1 OR e.ContactID = 2 GROUP BY e.ContactID FOR XML PATH

Таким образом, в элементе больше не остается произвольного текста:

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

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

1 ... 196 197 198 [ 199 ] 200 201 202 ... 346