Delphi и InterBase
Delphi Client/Server Suite предназначена для написания приложений, работающих как с локальными, так и с удаленными данными. В последнем случае с помощью Delphi создаются клиентские приложения (забегая вперед, заметим, что в многозвенной архитектуре с помощью Delphi создаются также и серверы приложений - промежуточное звено между приложением "тонкого" клиента и SQL-сервером).
Написание приложений, работающих с локальными СУБД в однопользовательском и многопользовательском (в архитектуре "файл-сервер") режимах, несколько отлично от написания клиентских приложений, работающих с удаленными БД в архитектуре "клиент-сервер". Выделим сначала общие черты:
• для доступа как к локальным, так и к удаленным данным могут использоваться компоненты TTable, TQuery;
• в качестве промежуточного компонента между НД и визуальными компонентами для работы с данными, используется компонент TDataSource;
• состав визуальных компонентов для работы с данными одинаков при доступе как к локальным, так и удаленным данным.
Однако необходимо помнить о следующих отличиях:
• компонент TTable для доступа к удаленным данным использовать не рекомендуется, поскольку он требует передачи всех данных результата выполнения запроса к серверу, а не только той их части, которая должна быть визуализирована (что имеет место для компонента TQuery);
изменение записей БД следует производить не методами Insert, Edit, Delete, Post, Cancel, а при помощи SQL-операторов INSERT, UPDATE, DELETE (выполняемых при посредстве компонента TQuery, метод ExecSQL);
подобная рекомендация является следствием того факта, что в отличие от доступа к локальным СУБД, где главенствует навигационный (по одной записи) доступ к данным, при обращении к удаленным БД используется язык SQL, оперирующий сразу множеством записей;
• следует уделять особое внимание управлению транзакциями и в первую очередь - выбору, адекватного потребностям приложения уровня изоляции транзакций;
• для соединения с удаленной БД всех компонентов, работающих с этой БД, следует использовать как можно меньше компонентов TDatabase (в идеале - один), определяемых в приложении явно (поскольку в этом случае можно управлять параметрами соединения с удаленной БД);
• бизнес-правила, где это возможно, следует переносить на сервер, разгружая от них клиентское приложение;
• для обращения к хранимым процедурам на сервере можно использовать компонент TStoredProc;
• следует стремиться как можно меньше загружать сетевой трафик путем явного старта и подтверждения транзакций (методы TDatabase Start Transaction, TDatabase Commit), поскольку изменения БД в рамках одной транзакции выполняются одним пакетом; когда подтверждение единичных изменений БД производится неявно стартуемыми и завершаемыми (в режиме SQLPASSTHRU = SHARED AUTOCOMMIT) транзакциями, это ведет к возрастанию графика и, как следствие, к замедлению работы, часто весьма существенному;
• следует уделять существенное внимание оптимизации запросов к БД, особенно при чтении данных (SELECT), поскольку оптимально построенный запрос может выполняться в несколько раз быстрее, чем неоптимальный, и требовать меньшего количества ресурсов для своего выполнения;
• компонент TIBEventAlerter, служащий для получения от сервера уведомления о наступлении событий, может применяться только при доступе к удаленным данным.
Приведенные выше особенности разработки клиентского приложения, так же как и особенности организации серверных БД и доступа к информации в них, будут рассмотрены в следующих разделах.