Нарощення

Багато невеликих мережних вузлів і додатків починаються з настільних систем на зразок Access. Однак у міру зростання обсягу бази даних стають усе більше очевидними недоліки процесора Jet, головний з яких – нездатність обслуговувати одночасно велику кількість користувачів. Програмне забезпечення баз даних, призначене для настільних систем, починає в таких випадках «глючити». Microsoft Access справляється з п’ятьма користувачами у локальній обчислювальній мережі (ЛОМ), але якщо до бази даних спробують одночасно пробитися двадцять користувачів, проблем не уникнути. Втім, настільна база даних і не розрахована на умови, звичні для Web.

Далі, бази даних Access, створювані на основі файлів, коли їхній обсяг досягає декількох мегабайт, стають досить ненадійними. До того ж, у системах класу Access немає засобів безпеки, якими володіють мережні СКБД. Приміром, базу даних Access неважко віднести із собою, просто скопіювавши її на диск. Навіть нестандартні установки виявляються легко доступними.

Саме через усе це, компанії стали переходити до більш складних систем, що використовують, як правило, SQL для комунікацій. Таким чином, незважаючи на те, що SQL сам по собі не має ніякого відношення до потужності системи, для взаємодії із СКБД, у якій забезпечені можливості нарощування потужностей, він стає необхідним.

13.2 Швидкість

Перші СКБД із підтримкою SQL були повільніші за своїх попередників. Однак у роки, у міру просування на ринок, були зроблені чималі зусилля по вдосконалюванню процесорів даних з підтримкою SQL. Поки компанії-розробники устаткування намагаються перевершити один одного, знижуючи вартість транзакції за рахунок підвищення швидкості комп’ютерів, постачальники програмного забезпечення домагаються того ж за рахунок підвищення ефективності СКБД.

Що стосується підвищення швидкості, то ця проблема вимагає уваги завжди, а не тільки в часи пікових навантажень. Звичайно вона виникає через занадто ускладнені запити із застосуванням методів, які нам ще потрібно буде розглянути, наприклад, зв’язування (оператор JOIN) непроіндексованих даних. Сам по собі SQL не здатний вирішувати проблеми швидкості, але вони вирішуються за рахунок установки більше швидкісних СКБД, яким SQL необхідний для комунікацій.

13.3 Ціна

Експлуатація СКБД, що розташовується на сервері (і спілкується винятково на SQL), обходиться значно дорожче, ніж використання настільної системи на зразок Access (для яких SQL необов’язковий). Причин декілька. По-перше, серверний варіант вимагає більш дорогого програмного забезпечення; по-друге, для нього, як правило, потрібно більше дорога операційна система; по-третє, настроювання ОС для СКБД відрізняється від настроювання для додатків, тому СКБД найчастіше доводяться розташовувати на окремому сервері; нарешті, для обслуговування серверної системи знадобиться більш кваліфікований, а тому й більш дорогий, персонал.

Проте, витрати на встаткування й програмне забезпечення становлять звичайно найменшу статтю бюджету інформаційного відділу. У міру нарощування потужності системи міркуванням надійності, ефективності й стандартизації СКБД із підтримкою SQL віддається перевага перед проблемами вартості.

Одне зауваження із приводу вартості: існує можливість майже безкоштовної організації СКБД на основі SQL. З Web можна завантажити пробні версії деяких СКБД. Треба, однак, пам’ятати, що безкоштовне використання пробної версії дозволяється обмежений час, тому організація бізнесу на основі СКБД із підтримкою SQL буде коштувати значно дорожче використання звичайної системи на зразок Access.

13.4 Універсальність

Альтернатива складанню SQL-операторів – написання функцій процедурною мовою на зразок Pascal. Однак ці функції виявляються прив’язаними до конкретних процедурних мов, метаданих і СКБД. Якщо відбуваються зміни в структурах таблиць, доводиться вносити зміни у функції. У випадку ж установки нової СКБД потрібно переглянути всю систему відповідно до нових покажчиків, визначеннями наборів записів і т.д. SQL вільний від цих проблем – всі необхідні для нього зміни відбуваються «за лаштунками» у самій СКБД без участі програміста.

13.5 Аналітичні можливості

Ще одна важлива особливість SQL – наявність аналітичних засобів (не розглянутих у посібнику), що дозволяють витягати корисну ділову інформацію з великого обсягу даних. Для цих завдань часто потрібне створення багатомірних конструкцій даних, і вони відомі під назвами OLAP (Online Analytical Processing – аналітична обробка в реальному часі), DDS (Decision Support Systems – системи прийняття рішень) і EIS (Executive Information Systems – управлінські інформаційні системи). Кожен постачальник включає в СКБД свою версію цих функцій і тільки в потужні системи, що використовують для комунікацій SQL.

14 У яких випадках СКБД із підтримкою SQL не потрібна

Попри все те, що нас цікавить у першу чергу SQL, не можна не обговорити ситуації, у яких перевагу може мати система, для якої ця мова не потрібно (наприклад, Access). Більшість із перерахованих нижче ситуацій саме такі.

ü З базою даних працює одночасно невелике число користувачів.

ü Для зберігання даних потрібно не більше 50 % доступного обсягу диска.

ü Обсягу носіїв і машинного часу цілком достатньо для виконання резервного копіювання.

ü Не передбачається істотного збільшення обсягу даних або числа користувачів.

ü Не планується забезпечення доступу до бази даних через Internet.

ü Більша частина використовуваних даних представлена не в реляційній формі (у файлах і папках).

При наявності більшої частини перерахованих умов, надавайте перевагу простішій й дешевшій СКБД Microsoft Access. При цьому більша частина роботи може виконуватися за допомогою майстрів і засобів перетаскування, що дозволить уникнути інвестицій в устаткування, програмне забезпечення й навчання персоналу роботі з SQL.

i Як уже було сказано, для роботи в Access SQL не потрібний, однак його підтримка в цій СКБД забезпечена. Це дозволяє використати дану систему для вивчення цієї мови.

Система на основі СКБД із SQL обходиться набагато дорожче СКБД на зразок Access, у якій для розробки бази даних використовується звичайний засіб перетаскування. Можливий варіант використання Access як прототипу, для обкатування форм і звітів у реальній роботі. Це дозволить скоротити час, затрачуваний на складання SQL-операторів при переході до остаточної версії системи. Більше того, значну частину SQL-операторів, складених в Access, можна буде перенести в нову систему без яких-небудь змін.

Далі ми обговоримо особливості деяких прикладних частин і зовнішніх інтерфейсів, потім розглянемо програмування з’єднання й передачу SQL-операторів від зовнішнього інтерфейсу до прикладної частини, а також обробку результатів, що повертають на зовнішній інтерфейс.