Теория СУБД

ЛОГИКА

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

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

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

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

ИТОГО

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

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

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