Архитектура «активный сервер баз данных»
Для того чтобы устранить недостатки, свойственные архитектуре сервера базы данных необходимо, чтобы непротиворечивость бизнес-логики и изменения БД контролировались на стороне сервера. Причём некоторые, заранее специфицированные состояния могли бы изменять последовательность взаимодействия приложения с БД.
Для этого функции бизнес-логики разделяются между клиентской и серверной частью. Общие или критически значимые функции оформляются в виде хранимых процедур, включаемых в состав БД. Кроме этого, вводится механизм отслеживания событий БД – триггеров, также включаемых в состав базы. При возникновении соответствующего события (обычно изменения данных), СУБД вызывает для выполнения хранимую процедуру, связанную с триггером, что позволяет эффективно контролировать изменение БД.
Хранимые процедуры и триггеры могут быть использованы любыми клиентскими приложениями, работающими с БД. Это снижает дублирование программных кодов и исключает необходимость компиляции каждого запроса (Рис. 19-3).
Рис. 19-3. Архитектура «активный сервер баз данных»
Недостатком такой архитектуры становится существенно возрастающая загрузка сервера за счёт необходимости отслеживания событий и выполнения части бизнес-правил.
Такую архитектуру организации взаимодействия и рассматриваемый далее сервер приложений иногда называют моделью с «тонким клиентом», в отличие от предыдущих архитектур, называемых моделью с «толстым клиентом», где на стороне клиента выполняется большинство функций.
Назад к разделу "Архитектура «выделенный сервер базы данных»"