Третий уровень

 

Многие программисты, которых я знаю, способны работать только с двухуровневой моделью, то есть с клиент-серверными приложениями. Не потому, что они больше ничего не знают, а потому, что просто не видят преимуществ трехуровневой модели и не хотят мучиться с лишними проб­лемами, а ведь в будущем, во время сопровождения программ, три уровня по идее могут спасти их от лишних бо­лезней анального отверстия.

Я работал в одной фирме (не будем тыкать в нее вилами), у которой было несколько офисов по России, и в каж­дом из них - парк компьютеров из 20-30 штук. В московском офисе эта цифра превышала сотню. Корпора­тивные программы обновлялись каж­дые две недели (вносились измене­ния, добавления и т.д.). Бедные админы в момент обновлений работали по субботам, чтобы пропатчить софт на каждой машине и убедиться в функ­циональности. Как решить эту проб­лему?

Самое простое – использовать тре­хуровневую систему: клиент, сервер логики (умники любят говорить "биз­нес-логика") и сервер приложения. В такой системе вся логика собрана в сервере приложений. Если что-то из­менилось в базе данных или в логи­ке обработки данных, достаточно об­новить его, и все клиенты будут ра­ботать по-новому без каких-либо патчей.

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

Представим себе классическую за­дачу – появление новой версии базы данных или переход на базу качест­венно более нового уровня. Ну не хватает нам уже возможностей MySQL, захотелось заполучить всю мощь Oracle. Для этого переустанав­ливается сервер баз данных, изменя­ется сервер приложений на подклю­чение к новой базе - и клиенты гото­вы к работе. Их обновлять не надо!

Но самое интересное то, что клиен­тская программа может быть какой угодно. Можно написать сценарии, ко­торые позволят работать с сервером приложении прямо из браузера. В этом случае с базой смогут работать пользователи на любой платформе (Windows, Linux и т.д.).

ЛОГИКА

 

Несмотря на наличие сервера при­ложений, нет смысла засовывать в него всю логику обработки данных. Если используется мощная база дан­ных, которая поддерживает хранимые процедуры и функции, то лучше пере­ложить часть логики на сервер базы. В этом случае внесенные в хранимый код изменения вступают в силу мо-

ментально и не надо даже обновлять сервер приложений.

Если в сети не так уж и много компь­ютеров (не больше 20-ти) и сервер достаточно мощный, то можно сервер приложений и базу данных располо­жить на одном физическом сервере. В этом случае обмен данными между сервером приложений и базой будет происходить внутри одного компьюте­ра, а не по сети, что может существен­но снизить нагрузку на сетевое обо­рудование.

Допустим, сервер приложений и ба­за данных находятся на разных сер­верах. Результаты запросов будут сначала идти через коммутатор от ба­зы данных к серверу приложений, а затем через тот же коммутатор к компьютерам клиентов. Таким обра­зом, по сети дважды пролетают одни и те же данные. Чтобы от этого изба­виться, я чаще всего объединяю в од­ном физическом сервере логику и данные.

ИТОГО

Что же выбрать для своего проек­та? Все очень просто. Если ты пи­шешь базу, с которой будет работать одновременно только один человек, то однозначный выбор – локальная база. Я больше всего люблю MS Access за его надежность и за то, что драйверы доступа к этой базе есть на всех компьютерах (особенно если там установлен MS Office) и их не надо тя­нуть с инсталлятором.

Если с базой будет работать хотя бы два человека, то не надо выдумывать сетевые коннекты, а лучше восполь­зоваться клиент-серверной техноло­гией. Она избавляет сеть от лишнего трафика, более надежна при много­пользовательской работе и дает мак­симальное количество возможностей.

Если количество пользователей ка­тастрофически увеличивается и по­являются проблемы с обновлением системы, то лучшим выходом будет переход на трехуровневую систему. Это немного сложнее в разработке, зато намного лучше во время сопро­вождения.

ВИДЫ СТРУКТУР БАЗ

 

База данных (БД) – это электронное хранили­ще какой-либо инфор­мации, имеющее свою определенную, наибо­лее удобную и функциональную структуру. Для создания баз данных и работы с ними используют различные СУБД (системы управления базами данных). Базы данных различаются по своей структуре: дореляционные (на инвертированных списках, иерар­хические системы и сетевые СУБД), реляционные и постреляционные (например, объектные).

СИСТЕМЫ, ОСНОВАННЫЕ НА ИНВЕРТИРОВАННЫХ СПИСКАХ

К числу наиболее известных представителей можно отнести Datacom/DB от компании Applied Data Research, Inc. (ADR). Организация дос­тупа к данным, основанная на инвер­тированных списках, очень распрост­ранена и применяется практически во всех современных реляционных СУБД. С тем лишь отличием, что в этих системах пользователи не имеют непосредственного доступа к инвер­тированным спискам (то есть к индек­сам). Общие правила для ограниче­ния целостности отсутствуют, и все возлагается на плечи прикладной программы.

ИЕРАРХИЧЕСКИЕ СИСТЕМЫ

Типичным представителем иерар­хических систем является Information Management System (IMS) фирмы IBM. Первая версия этого продукта вышла в свет в 1968 году.

Чтобы понять иерархическую мо­дель СУБД, попробуй представить се­бе дерево (представляет собой струк­туру данных) со всеми его ветками и выросшими от него другими деревья­ми. Причем к каждому листочку (сег­менту структуры) можно добраться только по одному определенному пу­ти, который начинается от корней (корневого сегмента).

Для этой модели существуют некото­рые базовые правила. Никакая запись-потомок не может существовать без за­писи-предка. Согласись, ветка, висящая в воздухе без дерева, - это бред! И вет­ка не может расти от двух деревьев сразу, то есть запись-потомок может иметь только одного предка.