Ole db або odbc сім раз відміряй
OLE DB і ODBC являють собою інтерфейси додатків, які забезпечують доступ до цілого ряду джерел даних. Розробники Microsoft спроектували ODBC для доступу до даних SQL, а OLE DB - для доступу до будь-яких даних в середовищі СОМ.
Чим же поганий ODBC?
Впровадження OLE DB не означає відмову від ODBC. У доступному для огляду майбутньому Microsoft планує підтримувати ODBC так само, як це роблять інші виробники СУБД і інструментальних засобів. Так чому ж не влаштовує розробників ODBC? Для доступу до даних він цілком адекватний. Досвід підтверджує, що, якщо ODBC задовольняє потреби вашого бізнесу, про OLE DB і пов'язаних з ним технологіях поки можна забути.
Однак ODBC перетворився в розвинуту, повністю виразити себе технологію, і Microsoft не далі його вдосконалювати. ODBC подібний поїзду, який перевозиться в депо, до якого залишилося всього кілька зупинок. На будь-якій зупинці можна пересісти на інший потяг, OLE DB, і кожен сам вирішує, коли це краще зробити.
Таким чином, ODBC цілком справляється зі своїми обов'язками. Добре відома його продуктивність, гнучкість і архітектура. Існує чимало різних інструментальних засобів і робочих середовищ, побудованих на ODBC (наприклад, RDO). Щоб зрозуміти, як скоро доведеться задуматися про перехід до OLE DB, проаналізуйте, якою мірою можливості ODBC відповідають тим удосконаленням, які планується впровадити у вашій інформаційній системі. При цьому потрібно пам'ятати про те, що протягом найближчих п'яти років ODBC буде надавати ті ж самі можливості, що і сьогодні. ODBC буде як і раніше забезпечувати доступ до даних SQL, які не інтегровані з іншими, нереляціоннимі типами даних, такими, як файли мови XML, документи Microsoft Office або файли електронної пошти. Якщо ж подібного роду файли є частиною інформаційних ресурсів компанії, варто розглянути варіант OLE DB.
Що нового пропонує OLE DB
OLE DB являє собою наступний щабель розвитку ODBC. Ці засоби утворюють відносно незалежний програмний шар, який використовує один і той же набір основних інтерфейсів прикладних програм (API) для доступу до різноманітних баз даних. Їх робота забезпечується невидимими для користувача програмними модулями, які враховують специфічні особливості кожної СУБД і виступають в якості драйверів для верхніх програмних шарів. В OLE DB повністю реалізований принцип відкритості зв'язків між базами даних. Найбільші відмінності виявляються у використанні деяких основних термінів і в навколишньому контексті. В Таблиці 1 містяться трактування часто вживаних термінів стосовно ODBC і OLE DB.
Таблиця 1. Інтерпретація основних термінів в ODBC і OLE DB.
Команда SQL, що інтерпретується підключеної СУБД
Текстовий рядок, яку розуміє джерело даних.
З точки зору функціональності OLE DB забезпечує доступ до всіх типів інформації: реляційним і нереляційних, плоским і ієрархічним, постійним і змінним, орієнтованим на SQL або на будь-який інший мову запитів. Для полегшення доступу до інформації джерела даних OLE DB представляються компонентами, що базуються на СОМ, з чітко визначеним програмним інтерфейсом. Ці компоненти, звані постачальниками даних, взаємодіють зі сховищем інформації. При з'єднанні з постачальником даних клієнтське додаток завжди отримує в якості відповіді набір записів незалежно від того, до чого звертається постачальник даних - до таблиці реляційної СУБД або до лістингу каталогу. Постачальник відповідає за вилучення даних з фізичного носія і їх форматування. Дані можуть зберігатися в одному і тому ж постійному місці (в файлах на диску або в базі даних), в певній галузі пам'яті або навіть на різних машинах і різних платформах. Вони можуть бути реляційними і ієрархічними, структурованими і плоскими, записаними в стандартному і в приватному форматі, доступними і недоступними для ODBC.
Повертається OLE DB результуючий набір (званий набором рядків або записів) являє собою не просто потік байтів, що записуються в пам'ять клієнтського додатка, як у випадку ODBC. Цей потік даних міститься в незалежному модулі СОМ з окремим програмним інтерфейсом. Такий модуль пропонує різні способи маніпулювання набором записів - сортування, фільтрацію, прокручування тексту. При цьому він допускає можливість одночасної роботи з даними багатьох користувачів. Працювати з набором рядків можна навіть при відключенні від початкового джерела даних, що робить тим самим цей новий потужний тип даних досить ефективним.
Перешкоди на шляху OLE DB
Так чи так уже хороший OLE DB? Для відповіді на це питання слід ретельно вивчити два аспекти. З одного боку, OLE DB не можна назвати цілком зрілої технологією. З іншого - Microsoft позиціонує його як базовий сервіс доступу до даних для майбутніх платформ Windows. Це означає, що в Microsoft планують істотно доопрацювати OLE DB. Розглянемо ці два аспекти більш докладно, щоб спробувати передбачити, який вплив вони матимуть на користувачів.
На рисунку 1 наведено для порівняння архітектури OLE DB і ODBC.
МАЛЮНОК 1. Архітектура ODBC і OLE DB.
Обидві базуються на спеціалізованих компонентах (драйвери в разі ODBC і постачальників в архітектурі OLE DB), які з'єднуються з джерелом даних. В рамках ODBC драйвер зазвичай виступає в ролі уповноваженого посередника, який передає команду SQL ядру СУБД, а назад повертає результуючий набір даних. Постачальник OLE DB приймає запити на будь-якій мові запитів (не обов'язково на SQL) і повертає набори записів. Постачальник, що інкапсулює СУБД, обмежується простою передачею команд SQL нижчому сервера бази даних. Постачальник, який взаємодіє з нереляційних джерелом даних (наприклад, з повідомленнями електронної пошти), виконує додаткову функцію: створює набір записів і наповнює його інформацією. Такий постачальник міг би працювати з більш простою мовою запитів, ніж SQL. Припустимо, для повернення повідомлення електронної пошти від замовника постачальнику необхідно знати тільки ім'я відправника. команда типу
проста, ефективна і легко кодується.
OLE DB складається з двох частин: зовнішнього інтерфейсу і внутрішнього ядра. Ядро, яке працює у фоновому режимі, обробляє запити і проводить пошук даних. Частина OLE DB, що відповідає за зовнішній інтерфейс, містить програмні засоби, необхідні будь-якому постачальнику для взаємодії з клієнтами. Тільки Microsoft може встановити стандарт на розвиток OLE DB з точки зору функціональності та технології. Для цієї мети задається специфікація інтерфейсу СОМ, який постачальник повинен підтримувати. OLE DB 2.5 демонструє значний прогрес у порівнянні з більш ранніми версіями: в ній зняті деякі обмеження проектування і додані нові можливості. Наприклад, OLE DB 2.5 дозволяє повертати нерегулярні, що не табульованого набори записів. OLE DB можна використовувати для показу напівструктурованих і ієрархічних даних, таких, як потоки XML, документи Word і Excel, вміст директорії файлової системи. Крім того, в новій версії зменшується обсяг інформації про постачальника, яку необхідно знати споживачеві. Замість специфікації складних командних рядків і рядків з'єднання зв'язатися з потрібним набором записів можна за допомогою синтаксису URL. Це властивість, зване прямий URL-зв'язком, дозволяє написати такий рядок з'єднання:
У цій інтуїтивно зрозумілою записи стоять ім'я постачальника даних outlookprovider і текст команди, що пропонує постачальнику просканувати директорію inbox і знайти всі повідомлення, відправлені абонентом Joe User. Остання версія інструментарію розробника на платформі Microsoft, SDK (Software Development Kit), частково повторює досягнення OLE DB 2.5.
Оскільки розробники Microsoft розглядають OLE DB в якості основної технології доступу до даних в середовищі Windows, користувачі в доступному для огляду майбутньому отримають всю необхідну підтримку для застосування OLE DB. Постачальники найважливішого продукту Microsoft в класі серверів баз даних, SQL Server, негайно відіб'ють у ньому всі нововведення OLE DB. Чи сприймуть ці нововведення виробники інших баз даних? На мій погляд, недолік OLE DB в тому, що його єдиною надійною опорою є виробники SQL Server версій 6.5 та 7.0. Відомо, що виробники OLE DB для Jet і Oracle випустили функціонально неповні продукти, в яких виявлено помилки, так що розробникам вони навряд чи будуть корисні. Версія OLE DB для Oracle виробництва корпорації Microsoft теж не вражає уяви, але тим не менш представляється найбільш прийнятною. Версія OLE DB 2.1 забезпечує доступ до даних з множинних програмних середовищ, але це поки що проблематично. Для того щоб технологія OLE DB перетворилася в стандарт, всім виробникам баз даних і, можливо, незалежним компаніям необхідно випустити повні версії постачальників даних для різних СУБД. Не виключено, що буде потрібно спільними зусиллями удосконалювати ці компоненти.
Загалом, OLE DB ще належить завоювати визнання і отримати репутацію надійного засобу, т. Е. Повторити шлях, пройдений за останні роки ODBC. Але OLE DB має достатній потенціал для того, щоб перевершити ODBC за різноманітністю підтримуваних джерел даних, гнучкості і зручності програмних інтерфейсів. Більш того, центральна роль OLE DB в архітектурі працюють під управлінням Windows розподілених додатків для Internet, DNA (Distributed InterNet Applications), а також в архітектурі DNS робить цю технологію реальним кандидатом на місце ODBC. Цілком ймовірно, OLE DB стане важливим компонентом при плануванні майбутніх стратегій доступу до даних. Але сліпо застосовувати її не слід.
Коли варто вибрати OLE DB
Якщо приймати рішення щодо OLE DB належить вже сьогодні, то на які фактори слід звернути увагу? Розробники Microsoft спроектували OLE DB з урахуванням вимог продуктивності, але з точки зору архітектури виклик OLE DB перетинає більше програмних шарів, ніж запит SQL, запущений безпосередньо з коду через інтерфейс API в ODBC. Тому при використанні ODBC процес відбувається трохи швидше. Щоб компенсувати цей недолік, розробники передбачили таку можливість: OLE DB дозволяє агрегувати і інтегрувати структурно різні типи даних і використовувати їх в Web-додатках.
Потрібно пам'ятати про те, що перейти до OLE DB не так-то просто. Це застереження актуально навіть для тих користувачів, які вже застосовують об'єктну модель: RDO, або Data Access Object (DAO), або навіть ADO версії більш ранньої, ніж 2.х. Особливо складним може бути перехід в разі використання СУБД, відмінною від SQL Server. Витрати при цьому окупляться тільки тоді, коли почнеться реальна експлуатація переваг інтеграції з додатками і системними послугами, які надає OLE DB. Якщо користувачі не знають, як реалізувати переваги гетерогенних запитів, які не задіюють сховища даних і не планують інтегрувати нереляційні типи даних (документи, електронні таблиці, електронну пошту), вони ризикують втратити продуктивність! (Або не виявити конкретних поліпшень після оновлення системи.)
Зазвичай я раджу своїм клієнтам переходити до OLE DB тільки тоді, коли це обумовлено нагальними потребами бізнесу (як описано вище). Те ж рекомендується і при створенні нових систем, так як в процесі проектування можна відразу закласти в них всі можливості, що надаються OLE DB. Гнучкість, інтеграція і однорідність - важливі якості OLE DB. Якщо вони необхідні для бізнесу компанії, то перехід до OLE DB може стати економічно ефективним.
Системи, що базуються на Internet, являють собою велику область застосування для OLE DB, хоча низька якість послуг деяких провайдерів здатне дискредитувати всіх зусиль. Для виклику віддалених компонентів через HTTP в мережі Web можна використовувати служби віддаленого доступу до даних, Remote Data Services (RDS). Реалізувати таку можливість дозволяє застосування в якості ключової технології розроблених компанією Microsoft компонентів доступу до даних, Microsoft Data Access Components (MDAS), які включають і OLE DB. Нарешті, на стороні клієнта OLE DB надасть для обробки від'єднані набори записів.
У OLE DB є сильні і слабкі сторони; ця технологія не виникла за помахом чарівної палички. Вона проходить стадію вдосконалення, щоб з часом перетворитися на визнаний стандарт. Познайомитися з нею стоїть сьогодні, а застосовувати - тільки тоді, коли ви будете готові отримати з цього конкретну користь.