Далі, незважаючи на те, що системи клієнт-сервер добре справляються з більшими базами даних, ріст кількості приводить до втрати якості, коли БД виявляються дуже великі (мільйони записів). Тиражування даних, часто пропоноване для рішення проблеми продуктивності, є потенційно небезпечним: при наявності декількох копій даних може наступити момент, коли вони перестануть збігатися, незважаючи на всі прийняті для синхронізації міри. А виходить, "...всі зусилля, витрачені на синхронізацію, виявляться марними, навіть якщо ця робота робиться дуже швидко". Тому мэйнфрейм розглядається як альтернатива рішенню клієнт-сервер у тих випадках, коли останнє приводить до тиражування даних (наприклад, спільна робота декількох великих груп користувачів, розкиданих по містах і весям, з єдиної БД) .
Один з підходів до рішення перерахованих проблем заснований на більше детальному аналізі взаємодії між клієнтом і сервером . Сервер характеризується видом надаваної послуги, центральне місце в корпоративних системах займають сервери баз даних і сервери додатків. Традиційним став погляд на технологію клієнт-сервер як на систему трьох взаємодіючих компонентів: подання (або front-end) - реалізує функції введення й відображення даних; додаток (business-logic) - поєднує чисто прикладні функції, характерні для предметної області; СУБД (resource manager) - управляє доступом до даних, контролює цілісність БД і т.д.
Ці компоненти можуть бути по-різному розподілені між комп'ютерами в мережі, і, звичайно ж, реалізовані різними засобами: віддалені дані; сервер бази даних; сервер додатків.
Перша модель найпростіша, саме вона знайшла втілення в перших реалізованих проектах. Головне її достоїнство - достаток інструментальних засобів розробки додатків для Windows, що працюють із SQL-серверами через стандартний інтерфейс ODBC. Що стосується недоліків, те, мабуть, більша частина критичних зауважень, висловлених на адресу всієї технології, насправді ставиться саме до цієї моделі: поганий відгук через надмірне завантаження мережі неможливість задовільного адміністрування додатків. Причина цього неприємного явища в тім, що різні по своїй природі функції змішуються в одній програмі. При колективній роботі над проектом, коли, кожен розроблювач автоматизує "свої" типи робочих місць, стає найвищою мірою складно контролювати взаємну несуперечність алгоритмів обробки даних, що вбудовують у численні компоненти front-end. Аналогічні труднощі виникають і при необхідності внесення наскрізних змін у проект.
В основі другої моделі лежить механізм збережених процедур - засіб програмування ядра СУБД. Сьогодні цей механізм реалізований у всіх SQL-серверах, представлених на ринку. Прикладний компонент оформляється як набір збережених процедур мови SQL і переноситься на комп'ютер - сервер БД. Переваги такого підходу очевидні: знижується трафик мережі, з'являється можливість централізованого адміністрування функцій обробки даних, а також їхнього поділу декількома додатками. Недоліки ж пов'язані з тим, що процедурне розширення SQL не є повноцінною мовою програмування. Відсутність засобів налагодження й тестування збережених процедур у більшості СУБД може перетворити їх у потенційно небезпечний механізм. Тому на практиці у вигляді збережених процедур звичайно реалізуються лише найпростіші функції, тісно пов'язані з доступом до даних, у той час як більша частина обробки даних як і раніше здійснюється на комп'ютері-клієнті. Така "змішана" модель сьогодні, мабуть, застосовується найбільше широко, однак для розробки систем масштабу підприємства вона виявляється малопридатної навіть у випадку задовільного рішення проблеми комплексного налагодження обох частин розподіленого додатка. Справа в тому, що ядро типової СУБД, орієнтованої на SQL, не зовсім підходить для організації балансу завантаження серверів, міграції процедур між серверами, виконання пріоритетних запитів і т.д.
Досить традиційним методом рішення проблем, властивих дволанцюговим моделям, стало виділення третьої ланки - сервера додатків. Програмне забезпечення, використовуване для створення серверів додатків, часто відносять до категорії "middleware". У світі реляційних СУБД це TUXEDO system, Microsoft Transaction Server, Digital ACMS й інших. Монітори транзакцій є посередниками між клієнтами й СУБД, дозволяючи зробити прикладну систему незалежної як від конкретної реалізації користувальницького інтерфейсу, так і від СУБД. Крім того, вони забезпечують баланс завантаження, а також можливість динамічної реконфігурації системи без зупинки серверів додатків.
Однак, як справедливо замічено в роботі, висока продуктивність "реляційної" трьох ланкової прикладної системи якщо й досяжна, то ціною значних витрат на покупку додаткового ПО й потужних комп'ютерів класу "сервер". Витрати на ПО зв'язані не стільки із придбанням самих серверів додатків, скільки з необхідністю значних інвестицій в інструментальні засоби розробки. У кожному разі для ефективної реалізації кожного із трьох компонентів доводиться використати різні підходи й мови програмування (у якості типової "трійки" можна назвати Visual Basic, Cи й розширений SQL), а виходить, про простоту й концептуальну єдність такої системи говорити важко.
Питання для самоконтролю:
Дати визначення основних понять теорії БД.
Які БД називається реляційною? Складові реляційної таблиці.
Первинний ключ та його призначення.
Види зв’язків між таблицями в реляційній БД.
Охарактеризувати відношення «один-до-багатьох».
Охарактеризувати відношення «один-до-одного».
Охарактеризувати відношення «багато-до-багатьох».
Вказати стандарти мови SQL. Що розуміють під реалізацією мови SQL?
В чому полягає технологія «клієнт-сервер»? Вказати функції клієнта і сервера.
Перелічити переваги технології «клієнт-сервер».
Сервер, його призначення. Перелічити види серверів.
Охарактеризувати універсальні сервери.
Охарактеризувати файл-сервери.
Охарактеризувати сервери доступу до даних.
Охарактеризувати сервери віддаленого доступу.
Охарактеризувати сервери розподілу ресурсів.
Які ви знаєте основні категорії команд мови SQL?
Які ви знаєте основні переваги мови SQL?
Які існують основні проблеми технології «клієнт-сервер»?
Які ви знаєте основні моделі реалізації взаємодії між клієнтом і сервером для подолання проблем технології «клієнт-сервер»?
