Главная » Microsoft SQL Server, Базы данных » Т-SQL еще рано сбрасывать со счетов

0

Пакетные запросы, с использованием интеграции CLR или без нее, остаются лучшим способом доступа к реляционной базе данных. Такие запросы можно создать только на языке Т-SQL. Естественно, можно реализовать их и в компонентах CLR, но разве сопоставимы затраты? Будет ли у оптимизатора такой же шанс сгенерировать наилучший план выполнения, если все запросы будут реализованы в коде .NET, а не в хранимых процедурах Т-SQL? Будет ли прозрачность такого стиля программирования адекватной удобству обеспечения защиты данных и сопровождения программного кода? Ответ на каждый из этих вопросов будет строго отрицательным. Именно поэтому SQL уверенно сохраняет свои позиции, и именно поэтому хранимым процедурам отдается предпочтение, а динамический SQL считается рискованным и трудно поддерживаемым решением.

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

Компания Microsoft как бы подсказывает нам, что цена перемещения кода интеграции CLR из базы данных на уровень приложения будет значительно меньше. Время покажет. Могут настать времена, когда выполнение запроса доступа к данным из компонентов CLR станет лучшим вариантом решения задачи, а может случиться и так, что использование старого доброго курсора Т-SQL обеспечит наилучшую структуру запроса. Большей частью CLR не заменяет пакетную обработку запросов, так же как Т-SQL нельзя назвать лучшим решением итеративной обработки наборов данных. Предполагая, что логика приложения корректно воплощена на уровне базы, лучше использовать Т-SQL для доступа к базе данных, a CLR — когда в одном запросе нужно выполнить нечто большее, нежели обычная операция доступа. Создание приложений на уровне базы данных с целью дальнейшего масштабирования на другие уровни является довольно сомнительным решением; оно будет требовать большего использования типов интеграции CLR, а не объектов T-SQL.

Резюме

В этой главе мы лишь кратко познакомились с обширной средой .NET Framework. Были представлены ключевые концепции общеязыковой среды выполнения CLR и объектно- ориентированного программирования в среде .NET Framework. Эти концепции являются фундаментом понимания технических требований, предъявляемых к созданию компонентов интеграции CLR в базе данных. Были также представлены все пять типов объектов SQL Server, которые можно создать с помощью интеграции CLR. Было показано, как для поддержки интеграции CLR используются новые классы .NET и какие новые инструкции DDL T-SQL необходимы для интеграции CLR в производственной базе данных. Было показано, как, сведя вместе все эти концепции, создавать и устанавливать объекты CLR в базе данных. Также мы поразмышляли о том, в каких случаях стоит подумать об интеграции CLR, а когда лучше применять старый добрый T-SQL.

Влияние интеграции CLR на SQL Server с выходом версии SQL Server 2005 все еще остается неизведанной территорией, однако ее потенциал неоспорим.

Создание запросов в брокере служб

Брокер служб (Service Broker) является одним из самых любимых мною компонентов SQL Server 2005. Эта мощная и одновременно простая в эксплуатации система обслуживания очередей позволяет создавать асинхронные сообщения и очереди их обслуживания на уровне абстракции базы данных, что обеспечивает высокую масштабируемость. Это существенно в любой архитектуре данных SOA.

Даже если вы создаете таблицу с подлежащей для выполнения работой (например, заказы, которые должны быть обработаны в системе MRP), то фактически вы создаете очередь. Для приложений брокер служб выполняет именно это — поддержку высокопроизводительных рабочих очередей, инте- гированных в SQL Server, с возможностью мониторинга и выполнения инструкций DDL.

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

Так как брокер служб по сути является всего лишь таблицей SQL Server, он наделен всеми встроенными в SQL Server возможностями транзакций и резервирования. Именно это отделяет брокер служб от других технологий обслуживания очередей, таких как MSMQ.

Очередь содержит один широкий столбец с телом сообщения, так как сообщение обычно содержит один файл XML, его фрагмент, или сообщение SOAP.

Технология брокера служб была внедрена толь- Новинка \ ко в версии SQL Server 2005, так что всю эту 2005     главу можно считать нововведением в SQL

Server.

Брокер служб по умолчанию отключен, поэтому первым шагом является его включение с помощью инструкции ALTER DATABASE:

ALTER DATABASE AdventureWorks SET ENABLE_BROKER;

Конфигурирование очереди сообщений

Брокер служб использует обмен сообщений (или метафору диалога), однако занимается он не только сообщениями. Объект брокера можно определить следующим образом.

1.              Тип сообщения определяет реальные требования, предъявляемые к сообщению.

2.              Контракт определяет соглашение между исходной и целевой службой, в которое входит тип сообщения, очередь и службы.

3.              Очередь хранит список сообщений.

4.              Служба взаимодействует с очередью, отправляя или получая сообщения на объектах источника и приемника.

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

Так как брокер служб интегрирован в SQL Server, его объекты создаются с помощью хорошо знакомой инструкции DDL CREATE.

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

CREATE MESSAGE TYPE HelloWorldMessage VALIDATION = WELL_FORMED_XML ;

CREATE CONTRACT HelloWorldContract

( HelloWorldMessage SENT BY INITIATOR);

Очереди источника и приемника также создаются с помощью DDL:

CREATE QUEUE [dbo].[TargetQueue] ;

CREATE QUEUE [dbo].[InitiatorQueue] ;

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

CREATE SERVICE InitiatorService ON QUEUE [dbo].[InitiatorQueue];

GO

CREATE SERVICE TargetService ON QUEUE [dbo].[TargetQueue]

(HelloWorldContract);

Когда объект брокера служб создан, его можно увидеть в списке узла Serve се Broker в окне Object Explorer.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии