Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Лекция №16

.docx
Скачиваний:
36
Добавлен:
03.02.2015
Размер:
104.67 Кб
Скачать

Разработка и защита баз данных в Microsoft SQL Server 2005

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

С появлением усовершенствованных в отношении производительности и более гибких ядер баз данных, как, скажем, в Microsoft SQL Server 2005, размывается граница между теми объектами, которые следует хранить в базах данных, и теми, которые хранить в них не следует. Раньше базы данных хорошо подходили для хранения только структурированных данных. Однако благодаря недавним достижениям в сфере технологий механизмов баз данных становится все более простым и более выполнимым хранение в базе данных и неструктурированных данных, таких, как документы и изображения. Хранить ли в базе данных все или только некоторые из данных внешних приложений, зависит от того, как эти данные используются.

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

Где хранить настройки приложений

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

Прежде чем выбрать модель управления настройками с помощью данных, следует сначала учесть некоторые доводы в пользу использования в приложении конфигурационных файлов. Если ваше приложение не нуждается в базе данных для какой-либо еще функции, возможно, не стоит включать в приложение базу данных только для параметров приложения. Аналогично, если приложение нуждается в параметрах уже в процессе загрузки, а на этом этапе процесса база данных обычно недоступна, то конфигурационный файл будет более естественным решением. (Раньше параметры приложения в подобных ситуациях обычно хранились в реестре Windows, но сейчас они чаще хранятся в конфигурационных файлах приложения.) Одним из главных преимуществ хранения параметров конфигурации приложения в файле является то, что этим файлом с легкостью могут манипулировать пользователи. XML-файл можно редактировать в Блокноте, поэтому любой пользователь может изменить параметры. Если необходимо предотвратить просмотр или изменение уязвимых настроек пользователями, то файлы конфигурации можно зашифровать.

Несмотря на недоступность в процессе запуска приложения, хранение параметров приложения в базе данных может быть выгодным. В базе данных можно управлять доступом к параметрам при помощи политики безопасности базы, в том числе, используя шифрование в SQL Server 2005. Это не даст пользователям, которые, возможно, не вполне представляют себе последствия сделанных изменений, возможности изменить параметры. Если вы используете какой-либо вариант ролевой модели безопасности (см. лекции 2-3), можно контролировать, кому предоставляется возможность изменять отдельные параметры приложения. Сохранение параметров приложения в базе данных будет также очень полезно в распределенных приложениях. Таким образом, вы сможете хранить такие разные параметры, как часовой пояс или офисные правила, в одном месте - базе данных. Эти параметры можно настроить так, чтобы приложение хранило различные версии настроек для разных пользователей или групп пользователей, а контролировать параметры смогут сотрудники, имеющие достаточную квалификацию. В табл. 1.1 показаны преимущества, предлагаемые каждым из двух вариантов.

Совет. Если вы хотите использовать преимущества, предоставляемые хранением параметров в базе данных, но не хотите утяжелять клиент полнофункциональной базой данных, подумайте о реализации хранения параметров приложения в базе данных средствами программы Microsoft SQL Server 2005 Express Edition, которая распространяется бесплатно, или Microsoft SQL Server 2005 Workgroup Edition, стоимость которой является убедительным доводом в пользу ее применения для небольших реализаций.

Таблица 1.1. Сравнение вариантов хранения параметров приложения

Особенность

Хранение в базе данных

Хранение в конфигурацином файле

Пользователь может легко изменить параметры

?

Приложение не требует для работы ядра СУБД

?

Параметры доступны в процессе загрузки приложения

?

В приложении можно реализовать ролевую модель обеспечения безопасности

?

В приложении можно реализовать централизованное управление параметрами

?

В приложении можно легко ограничить доступ к параметрам

?

В приложении может быть обеспечен гранулярный контроль над параметрами

?

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

Где хранить пользовательские настройки

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

Реализация таблицы пользовательских настроек

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

  2. После того, как вы определите, какие параметры нужно хранить, разработайте необходимую для хранения параметров таблицу. табл. 1.2 представляет собой примерный проект таблицы для управления пользовательскими настройками в базе данных.

    Таблица 1.2. Примерный проект таблицы для хранения пользовательских настроек

    Имя логического столбца

    Назначение

    Идентификатор пользователя

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

    Дата добавления пользователя.

    В этот столбец записывается дата добавления Первая запись о пользовательских настройках обычно создается после добавления пользователя.

    Дата обновления настроек

    Помогает управлять активными пользователями и проверять актуальность их настроек. Обновление данных часто является более важным, чем их создание.

    Последний вход в систему

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

    Столбец или столбцы для хранения пользовательских настроек

    В этот столбец записываются пользовательские настройки, которые необходимо сохранить.

  3. Существует две распространенных реализации столбцов пользовательских настроек. Первая реализация - реляционная. Каждая настройка в этой реализации хранится в отдельном столбце таблицы. С этим решением связана следующая проблема: чтобы добавить дополнительную настройку, придется расширять таблицу путем добавления столбца. Второй вариант - все пользовательские настройки хранятся в одном столбце. С появлением XML можно использовать XML-документ для хранения нужных настроек либо в столбце TEXT, либо в столбце с типом данных XML; об этом речь пойдет далее в этой лекции.

  4. Затем продумайте, какие объекты данных необходимы для извлечения и управления таблицей пользовательских настроек. Вот что для этого нужно:

  • Хранимая процедура Insert. С помощью этой процедуры добавляется начальная запись пользовательских настроек. Часто это делается при добавлении пользователя, поэтому данную процедуру можно объединить с процедурой добавления пользователя.

  • Хранимая процедура Update. Обновляет запись пользовательских настроек. Эта процедура часто вызывается для управления пользовательскими настройками в приложении.

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

  • Хранимая процедура Delete. Предназначена для удаления записи пользовательских настроек. Эта операция, как и операция вставки, может выполняться в составе процедуры удаления пользователя. Однако вам нужно будет выполнить эти две процедуры по отдельности, если придется поддержать концепцию, например, сбросить пользовательские настройки на значения по умолчанию.

Где хранить XML-документы

Несколько лет назад XML-документы были новым веянием, но сейчас они уже стали привычными. Весьма вероятно, что вы уже видели и применяли XML-документы для настройки конфигурации и других задач в приложениях, с которыми работали. В SQL Server 2005 и Microsoft .NET Framework XML-документы широко используются для настройки параметров конфигурации и реализации других функций, таких, как службы интеграции SQL Server Integration Services (для которых XML хранятся в файлах .dtsx ) и службы составления отчетов SQL Server Reporting Services (данные XML хранятся в файлах с расширением . rdl ). XML имеет ряд преимуществ, не последнее из которых - гибкость при изменении требований к конфигурации приложения. Как было отмечено ранее, файлы XML также дают возможность пользователям приложения легко изменять параметры конфигурации.

XML также прекрасно справляется с хранением иерархических данных. Вот несколько примеров иерархических данных: магазинные чеки, спецификации материалов и счета за медицинское обслуживание. Все они включают родительские записи с дочерними записями разных уровней. Извлечение полных наборов этих данных из механизма базы данных может быть затруднено, но XML хранит данные в форме, позволяющей легко просмотреть данные. Поскольку XML очень эффективен и все более широко используется, разработчики компании Microsoft включили в SQL Server 2000 и SQL Server 2005 тип данных XML, а также реализовала особый механизм оптимизации и операторы T-SQL для управления XML-данными.

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

Поддержка XML в SQL Server 2005

В SQL Server 2005 разработчиками Microsoft в механизм базы данных были добавлены несколько новых специфических XML-функций. Эти усовершенствования позволили облегчить доступ к XML-данным и манипуляции с ними. Ниже перечислены некоторые из таких усовершенствований:

  • Собственный тип данных XML

  • Поддержка XML-схем

  • Возможность использования запросов XQuery к XML-данным, которые хранятся в столбцах с типом данных XML и в переменных

  • Возможность индексировать XML-данные, которые хранятся в столбцах XML

  • Поддержка языка манипулирования данными XML (XML-DML)

  • Усовершенствование существующих функций SQL Server 2000 для работы с XML, в том числе добавление ключевых слов OPENROWSET, FOR XML и OPENXML

Использование типа данных XML

В SQL Server 2005 появляется полнофункциональный тип данных XML. Благодаря этому типу данных становится возможным использовать свойственные XML SQL-запросы для поиска XML-данных и доступа к ним. Этот тип данных доступен и для таблиц, и для переменных. Если вы храните данные с использованием типа данных XML, то для запроса к ним можно использовать реализацию языка запросов XQuery в SQL Server. До появления типа данных XML при необходимости выполнить запрос к этим данным проектировщикам приходилось сначала извлекать их в реляционную версию. Необходимость извлечения XML-данных в таблицы и столбцы (эта методика получила название разбивки данных) с целью получения возможности запрашивать эти данные ограничивала гибкость, присущую XML-документам. Теперь, благодаря возможности использовать тип данных XML, разработчики могут ссылаться на содержимое документа, не прибегая к его разбивке на строки и столбцы. В табл. 1.3 перечислены поддерживаемые в SQL Server 2005 методы манипуляций с типом данных XML.

Таблица 1.3. Методы языка XQuery, поддерживаемые в SQL Server 2005

Метод

Синтаксис

Назначение

query()

.query(выражение XQuery)

Выполняет выборку данных в XML-документе или фрагменте аналогично оператору SELECT.

value()

.value (выражение XQuery, тип данных SQL)

Объединяет функциональность метода query() с функцией CONVERT языка SQL. Это позволяет выполнить выборку значения из XML-документа или фрагмента и конвертировать результат в определенный тип данных.

exist()

.exist (выражение XQuery)

Возвращает значение TRUE, если искомое выражение обнаружено в XML-документе; метод аналогичен оператору EXISTS в T-SQL.

modify()

.modify (выражение XML-DML)

Позволяет добавлять, обновлять или удалять узлы в документе XML. Метод modify() следует использовать в предложении оператора UPDATET-SQL

nodes()

.nodes(выражение XQuery) as ИмяТаблицы(ИмяПоля)

(См. информацию о XML-DML на справочном ресурсе SQL Server Books Online.) Позволяет выполнить разбивку документа и разместить результаты в реляционном формате

В следующем примере демонстрируется, как можно выполнить запрос к XML-данным в переменных XML.

Применяем метод Query() языка XQuery

  1. В меню Start (Пуск) выберите All Programs, Microsoft SQL Server 2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда SQL Server Management Studio).

  2. В окне Microsoft SQL Server Management Studio создайте новый запрос, нажав кнопку New Query (Создать запрос). (Готовый запрос можно найти в файлах примеров под именемXQueryQueryMethod.sql ).

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

DECLARE @SampleXML XML

  1. Запишите в переменную выражение XML, добавив в панель запросов следующий код:

  2. SET @SampleXML = '<root>

  3. <L1>

  4. <L2>Это первая строка</L2>

  5. </L1>

  6. <L1>

  7. <L2>Это вторая строка</L2>

</L1> </root>'

  1. Чтобы извлечь значения из узла L2, воспользуйтесь методом query(). Введите в панель запроса следующий код:

SELECT @SampleXML.query('/root/L1/L2')

  1. Выполните запрос, нажав кнопку Execute (Выполнить) на панели инструментов или функциональную клавишу F5. В панели результатов будут отображены следующие результаты:

  2. <L2> Это первая строка</L2>

<L2> Это вторая строка</L2>

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

Следующий код (который можно найти в файлах примеров под именем XQueryQueryDataMethod.sql ) демонстрирует пример использования метода data() для возвращения определенного фрагмента XML-данных, не заключенных в тэги XML:

DECLARE @SampleXML XML SET @SampleXML =

'<root>

<L1>

<L2>Это первая строка</L2>

</L1>

<L1>

<L2>Это вторая строка</L2>

</L1>

</root>'

SELECT @SampleXML.query("data(/root/L1[L2 = "Это вторая строка"])")

Должен получиться результат "Это вторая строка".

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

DECLARE @SampleXML XML, @Exists bit

SET @SampleXML =

'<root>

<L1>

<L2>Это первая строка</L2>

</L1>

<L1>

<L2>Это вторая строка</L2>

</L1>

</root>'

SET @Exists = @SampleXML.exist("/root/L1/L2[text() =

"Это первая строка"]")

SELECT @Exists

Результирующий набор будет содержать значение 1.

Одно из преимуществ использования переменных XML заключается в том, что можно классифицировать столбец с другим типом данных, например, TEXT или VARCHAR, как XML, а затем применить методы XQuery к данным в этом столбце. Если вы используете XML в уже имеющейся среде SQL Server 2000, то, всего вероятнее, данные хранятся в полях TEXT илиVARCHAR. В среде SQL Server Management Studio можно просмотреть данные в XML-формате. Это было невозможно в модуле Query Analyzer, который возвращал данные в виде нескольких строк. Следующий пример кода показывает, как классифицировать текстовые данные как XML.

SELECT CAST(textdata AS XML)

FROM dbo.SomeTable

WHERE SomeColumnID = 1

На рис. 1.1 показаны результаты запроса, который возвращает XML-данные, отображаемые в виде строки, в SQL Server Management Studio.

Рис. 1.1.  Результаты запроса XQuery, отображаемые в SQL Server Management Studiio в виде строки

Если щелкнуть ссылку в панели результатов, как показано на рис. 1.1, то вы увидите результат, отображенный в виде XML, как показано на рис. 1.2.

увеличить изображение Рис. 1.2.  Так выглядит результат запроса, отображаемый в SQL Server Management Studio в виде XML после перехода по ссылке в панели результатов

Типизированный или нетипизированный XML?

SQL Server 2005 поддерживает использование XML-схем с типом данных XML. На рис. 1.3 показано размещение коллекции схем в SQL Server Management Studio. Если вы используете схемы, или коллекции схем, как они называются в SQL Server, то SQL Server применяет схему к XML-данным, хранимым в таблице. При применении схемы принудительно применяются типы данных и ограничения посредством выполнения синтаксического анализа на основе схемы, которая загружается в столбец с типом данных XML. Можно гарантировать форматирование XML-данных, используя типизированные столбцы XML.

Рис. 1.3.  Размещение коллекции схем в SQL Server Management Studio

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

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

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

Использование файловой системы с XML-данными

Несмотря на то, что в SQL Server 2005 были внесены заметные усовершенствования в способ хранения XML в базе данных, по-прежнему можно обращаться к XML-документам, хранящимся вне базы данных. При помощи операторов FOR XML и OPENXL вы сможете записать XML-фай-лы и выполнить разбивку этих файлов для вставки в базу данных. Оба оператора были доступны в SQL Server 2000 и по-прежнему функционируют в SQL Server 2005. Более того, можно использовать оператор OPENROWSET для массовой высокопроизводительной загрузки XML-документов в базу данных.

Где хранить файлы внешних приложений

Не исключено, что вы окажетесь в такой ситуации, когда для поддержки вашего приложения будут необходимы файлы других типов - документы Microsoft Word (файлы .doc ), электронные таблицы Microsoft Excel (файлы .xls ), изображения (файлы .jpg или .bmp ), видео (файлы .mpeg ), или даже звуковые файлы (файлы .wav ). Где лучше хранить эти файлы, если они необходимы бизнес-приложению? Существует два широко используемых метода хранения таких файлов:

  • Хранение файлов в файловой системе со ссылкой на них в базе данных.

  • Хранение файлов в виде больших объектов в столбцах LOB в таблице базы данных.

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

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

Если файлы хранятся в файловой системе, то это дает такие же преимущества, которые были ранее рассмотрены для хранения настроек приложения в конфигурационном файле. Вы можете быстро обратиться к этим файлам при помощи старых испытанных методов, например, через Проводник Windows в Microsoft Windows. Пользователи смогут обратиться к этим файлам вне контекста приложения (что может быть желательным или нежелательным, в зависимости от того, как используются файлы). Если вы работаете с файлами, используя репозиторий документов, то ссылка на файлы из таблицы, вероятно, подойдет для вашего случая – при этом таблица хранится в упрощенной форме, способствующей ускорению поиска. Однако если приложение зависит от отдельных характеристик файла, например, если нужно, чтобы Столбец А в Excel содержал номера счетов, то предоставление пользователям возможности доступа к этим файлам подвергает риску целостность приложения.

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

Примечание: Если вы интересуетесь тем, может ли SQL Server обрабатывать хранение файлов в таблице базы данных, особенно если вам приходится хранить несколько предыдущих версий, попробуйте обратиться к инструменту координации совместной работы от Microsoft - Windows SharePoint Services (поставляется с Microsoft Windows 2003) и Microsoft Office SharpPoint Portal Services. Любое из этих приложений использует базы данных SQL Server для управления файлами, сохраняя версии файлов в таблицах базы данных.

Заключение

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

Краткий справочник по 1 лекции

Для того чтобы

Выполните следующие действия

Запустить среду SQL Server Management Studio

В меню Start (Пуск) выберите команду All Programs, Microsoft SQL Server2005, SQL Server Management Studio (Все программы, Microsoft SQL Server 2005, Среда Server Management Studio)

Ввести и выполнить новый запрос в SQL Sever Management Studio

Нажмите кнопку New Query (Создать запрос), введите текст запроса в панели запроса и нажмите кнопку Execute (Выполнить).

Просмотреть XML-данные для строки, возвращенной запросом

Щелкните на ссылке в панели Results (Результаты), которая находится под окном запроса.

Использовать метод XQuery query(), чтобы возвратить данные, хранящиеся в переменной SampleXML.

Используйте предложение T-SQL SELECT @SampleXML.query("/root/L1/L2)")

Соседние файлы в предмете Безопасность систем баз данных