Т-SQL ще рано скидати з рахунків

Пакетні запити, з використанням інтеграції 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&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Тип повідомлення визначає реальні вимоги, пропоновані до повідомлення

2&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Контракт визначає угода між вихідною і цільової службою, в яке входить тип повідомлення, черга і служби

3&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Черга зберігає список повідомлень

4&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Служба взаємодіє з чергою, відправляючи або одержуючи повідомлення на обєктах джерела і приймача

Окрім визначення типу повідомлення як 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 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*