45866 (762172), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Говоря об оптимизации клиент-серверных информационных систем, хотелось бы отдельно остановиться на одной очень распространенной ошибке, совершаемой программистами, имеющими большой опыт работы с настольными СУБД и средствами разработки, базирующимися на xBase-языках, такими, как Clipper, dBase, FoxPro и др. При использовании средств разработки такого рода какое-либо изменение данных в таблице согласно каким-либо правилам осуществляется обычно путем создания цикла типа:

USE HOLDINGS

GO TOP

DO WHILE !EOF()

PUR_PRICE=PUR_PRICE+10

SKIP

ENDDO

CLOSE

В приведенном фрагменте xBase-кода PUR_PRICE - имя поля таблицы HOLDINGS, подверженного изменению.

При переходе к архитектуре клиент/сервер и средствам разработки, поддерживающим SQL, поначалу возникает естественное желание продолжать писать подобный код, используя циклы и навигацию по таблице. Это не так страшно в случае использования C++Builder с настольными СУБД - локальный SQL, способный быть альтернативой в этом случае, в конечном итоге также инициирует перебор записей таблицы. Вообще говоря, то же самое происходит и при выполнении запроса типа UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10 на сервере баз данных, но подобный цикл является внутренним процессом сервера, в котором не задействованы ни клиент, ни сеть. Однако при использовании "клипперного" стиля программирования библиотека BDE вовсе не обязана догадываться, что имел в виду программист, написавший подобный цикл, и генерирует вовсе не такие запросы!

Рассмотрим простой пример. Создадим копию таблицы HOLDINGS.DBF из входящей в комплект поставки C++Builder базы данных DBDEMOS на каком-либо сервере баз данных, например, Personal Oracle (воспользовавшись, например, утилитой Data Migration Wizard из комплекта поставки Borland C++Builder). Затем создадим новое приложение, состоящее из одной формы, включающей компоненты TDBGrid, TTable, TDataSource, TQuery, TDBNavigator и три кнопки (рис.3).

Установим следующие значения свойств используемых компонентов (табл.1):

Таблица 1.

Компонент	Свойство	Значение
DBNavigator1	DataSource	DataSource1
DBGrid	DataSource	DataSource1
Button1	Caption	'Use SQL'
Button2:	Caption	'Update records'
Button3:	Caption	'Exit'
DataSource1	DataSet	Table1
Table1	DatabaseName	ORACLE7
	TableName	HOLDINGS
	UpdateMode	UpWhereKeyOnly
Table1PUR_PRICE	FieldName	'PUR_PRICE'
Query1	DatabaseName	ORACLE7
	SQL	'UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10'

Теперь создадим обработчики событий, связанные с нажатием на кнопки. Кнопка Update records реализует аналог фрагмента xBase-кода, приведенного выше:

void __fastcall TForm1::Button2Click(TObject *Sender)

{

Table1->First();

DataSource1->Enabled=false; //Не будем издеваться над видеоадаптером!

while (!Table1->Eof)

{

Table1->Edit();

Table1PUR_PRICE->Value=Table1PUR_PRICE->Value+10;

Table1->Next();

}

DataSource1->Enabled=true; //Посмотрим, что получилось...

}

Временное отключение связи между DataSource1 и Table1 в данном обработчике событий сделано для того, чтобы исключить перерисовку компонента DBGrid1 при изменении каждой записи.

Кнопка Use SQL реализует выполнение одиночного SQL-запроса UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE+10:

void __fastcall TForm1::Button1Click(TObject *Sender)

{

Query1->Prepare();

Query1->ExecSQL();

Table1->Refresh(); //Посмотрим на результат...

}

Скомпилировав приложение, запустим SQL Monitor и посмотрим, какие запросы генерируются BDE при нажатии на эти кнопки.

При использовании кнопки Update records log-файл имеет следующий вид:

14:37:08 SQL Prepare: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

14:37:08 SQL Execute: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

14:37:08 SQL Stmt: ORACLE - Close

14:37:08 SQL Prepare: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:08 SQL Execute: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:08 SQL Misc: ORACLE - Set rowset size

14:37:08 SQL Stmt: ORACLE - Fetch

14:37:08 SQL Stmt: ORACLE - EOF

14:37:08 SQL Stmt: ORACLE - Close

14:37:08 SQL Prepare: ORACLE - UPDATE "HOLDINGS" SET "PUR_PRICE"=:1 WHERE "ROWID"=:2

И так далее, пока не кончатся все записи:

14:37:10 SQL Prepare: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:10 SQL Execute: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:37:10 SQL Misc: ORACLE - Set rowset size

14:37:10 SQL Stmt: ORACLE - Fetch

14:37:10 SQL Stmt: ORACLE - EOF

14:37:10 SQL Stmt: ORACLE - Close

Отметим, что это еще не самый большой набор запросов для данного случая, так как при обновлении таблицы было использовано значение UpWhereKeyOnly свойства UpdateMode компонента Table1, при котором запросы на обновление одной записи имеют минимальный набор проверяемых параметров.

При использовании кнопки Use SQL log-файл имеет совершенно другой вид:

14:35:51 SQL Prepare: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:35:51 SQL Transact: ORACLE - Set autocommit on/off

14:35:51 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10 14:35:51 SQL Stmt: ORACLE - Close

Остальные SQL-запросы, содержащиеся в log-файле, генерируются BDE при выполнении метода Refresh() компонента Table1:

14:35:51 SQL Prepare: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:35:51 SQL Execute: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE "ACCT_NBR"=:1

14:35:51 SQL Misc: ORACLE - Set rowset size

14:35:51 SQL Stmt: ORACLE - Fetch

14:35:51 SQL Stmt: ORACLE - EOF

14:35:51 SQL Stmt: ORACLE - Close

14:35:51 SQL Prepare: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE (("ACCT_NBR" IS NULL OR "ACCT_NBR"> :1)) ORDER BY "ACCT_NBR" ASC

14:35:51 SQL Execute: ORACLE - SELECT "ACCT_NBR" ,"SYMBOL" ,"SHARES" ,"PUR_PRICE" ,"PUR_DATE" ,"ROWID" FROM "HOLDINGS" WHERE (("ACCT_NBR" IS NULL OR "ACCT_NBR"> :1)) ORDER BY "ACCT_NBR" ASC

14:35:51 SQL Misc: ORACLE - Set rowset size

14:35:51 SQL Stmt: ORACLE - Fetch

Если из текста обработчика события Button1Click удалить строку

Table1->Refresh();,

то действия с 5-го по 14-е выполняться не будут. Кроме того, при нажатии на эту же кнопку несколько раз подряд log-файл будет иметь следующий вид:

14:11:36 SQL Prepare: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:11:36 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:11:40 SQL Stmt: ORACLE - Reset

14:11:40 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:14:17 SQL Stmt: ORACLE - Reset

14:14:17 SQL Execute: ORACLE - UPDATE HOLDINGS SET PUR_PRICE=PUR_PRICE-10

14:14:19 SQL Stmt: ORACLE - Reset

Как видим, компиляция запроса сервером осуществляется в этом случае только один раз.

Итак, мы видим, что "клипперный" стиль программирования при работе с SQL-серверами абсолютно неприемлем - он приводит к перегрузкам сервера, сети и рабочей станции одновременно, а разница в скорости выполнения заметна даже при небольшом объеме таблицы и использовании локального сервера, поэтому, анализируя причины низкой производительности приложений, стоит посмотреть - а нет ли в клиентском приложении подобных фрагментов кода?

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

Список литературы

Для подготовки данной работы были использованы материалы с сайта http://www.realcoding.net/

Характеристики

Список файлов статьи