|
Страница 26 из 38
BDE и InterBase - тормоза-братья Несмотря на тормозологическую развитость InterBase фирма Borland не ограничилась только серверной частью своей архитектуры и разработала соответствующий продукт для клиента. По логике вещей - BDE должен отделять приложения от особенностей конкретной СУБД, подстраивая поступающие с клиентов запросы оптимальным образом. На деле же во многих случаях происходит наоборот - драйвер InterBase от той же фирмы Borland использует лишь часть возможностей этого сервера и его языка, причём далеко не лучшим образом. При этом средства разработки от Borland часто стимулируют использование как раз тех вещей, которые максимально тормозят обработку. И так, клиенты через BDE к серверу и открывают датасеты (наборы записей). Открыть их можно с помощью SQL-запроса select, или просто указав имя таблицы (представления). Открытый датасет можно листать вперёд-назад, можно искать запись по значениям полей, можно накладывать фильтр по связям с другими датасетами или по (почти) произвольному выражению. Кроме того, можно обновлять текущую запись в датасете или исполнять произвольные "обновляющие" запросы, не заботясь об управлении транзакциями на уровне отдельных операторов. Казалось бы, всё замечательно, но ... Метаданные Драйвер InterBase обожает читать свои собственные метаданные по каждому поводу. При каждой попытке открыть в первый раз за сеанс таблицу или запрос получается по моим наблюдениям как минимум пара запросов к таблицам RDB$XXXX. Самое интересное, что эти таблицы, будучи довольно сильно нагруженными, во многих случаях не проиндексированы или проиндексированы далеко не по всем полям, по которым идёт поиск. После более длительных наблюдений у меня сложилось впечатление, что индексируются только те поля, которые участвуют в соединении нескольких таблиц. Это, конечно, правильное решение, но соединение - не единственная операция, требующая индексирования. Конкретные ситуации лучше исследовать с помощью SQL-монитора. В пределах сеанса работы BDE обычно помнит метаданные, так что если открыть эту же таблицу с теми же параметрами или запрос с тем же исходным текстом, то повторных чтений обычно не происходит. Но стоит только что-то изменить (скажем, фильтр у таблицы или условие where у запроса), как при следующей попытке открыть это дело будет вновь прочитана куча того же мусора. Мораль: даже мелкий с виду запрос через BDE может проделать кучу непредвиденной работы. Частично данную проблему можно решить с помощью механизма Schema Cache (кэширование схемы), реализованного в драйвере InterBase. В его настройках надо указать каталог на локальном диске, где хранить метаданные, количество таблиц, метаданные которых можно туда выгружать и срок хранения, в течение которого метаданные считаются годными. Однако, как обычно, одно неудобство меняется на другое. Если до истечения таймаута сделать что-нибудь вроде alter table, то у клиента всё равно останутся старые метаданные. В результате - глюки и ругань на массовое несоответствие типов. Это, конечно, редко случается в реально эксплуатируемой системе, но в процессе разработки - сплошь и рядом. В таких случаях лучше отключить Schema Cache и терпеть. Или, если уж нехорошая ситуация возникла эпизодически, остановить все клиентские приложения в машине и стереть содержимое каталога, отданного под Schema Cache. |