Преобразование настольного приложения Access в приложение с архитектурой "клиент-сервер"


Приложение, разработанное в среде Access, является настольным приложением. Оно может быть предназначено для одного пользователя или может быть многопользовательским. Оно может быть простым или достаточно сложным, как, например, приложение, рассмотренное , в котором взаимодействуют несколько процессов. Однако все эти процессы работают под управлением настольной СУБД Access, a настольная СУБД имеет ограничения как по количеству одновременно работающих пользователей, так и по объему базы данных. С увеличением сложности приложения и накоплением данных в таблицах Access может возникнуть необходимость перенесения этих данных на сервер баз данных, который работает на значительно более мощной программно-аппаратной платформе. В этом случае приложения Access 2010 устанавливаются на клиентских машинах и играют роль клиентов, обращающихся к данным, хранящимся в базах данных SQL-сервера.
В клиент-серверных информационных системах на компонент "сервер" возлагается задача надежного хранения данных и обработки запросов клиента, в то время как от "клиентской" части требуется лишь обеспечение удобного интерфейса пользователя. Поэтому компонент "сервер" исполняется на специальной серверной платформе, которая обеспечивает серверное приложение необходимыми ресурсами и мощностью, а компонент "клиент" исполняется на менее мощной аппаратно-программной платформе. В нашем случае мы рассматриваем систему с серверной СУБД Microsoft SQL Server, работающей под управлением Windows NT Server, и клиентскими частями, управляемыми менее мощными СУБД Microsoft Access 2002.
Целесообразность перехода к клиент-серверной архитектуре
Выбор архитектуры приложения главным образом зависит от поставленной задачи. Многие задачи успешно реализуются в небольших сетях с файловым сервером. В других случаях нужно применять более мощную клиент-серверную архитектуру. Преобразование настольного приложения в клиент-серверное (upsizing) целесообразно с точки зрения обеспечения четырех важнейших требований:

  • надежность;
  • масштабируемость;
  • производительность;
  • безопасность.

 

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

Тип обработки

Преимущества использования сервера

Большой объем транзакций, выполняемых над многими таблицами
 

Сетевой трафик уменьшается за счет передачи по сети только запросов клиентов и результатов обработки. Вследствие этого уменьшается время ожидания обработки запроса при той же стоимости аппаратуры. Дополнительное преимущество заключается в улучшенном управлении блокировками

Выполнение нетривиальных запросов над совместно используемыми данными

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

Изменение небольшого числа полей (даже одного) в большом количестве записей

Сетевой трафик значительно уменьшается, поскольку по сети передаются лишь измененные поля
 

Массивная обработка данных над большими таблицами

Мощность серверной СУБД в сочетании с аппаратными возможностями самого сервера позволяет значительно повысить производительность

Иногда полезно некоторые таблицы перенести на сервер, но такие процедуры, как анализ данных, составление сложных отчетов путем слияния многих таблиц, лучше оставить на клиентских станциях. Можно даже все данные держать на сервере и дать возможность загружать нужные таблицы целиком на рабочие станции для анализа.