Ускорить чтение из базы

[ZBEP]

Здравствуйте!
В общем есть база (mdb), объем ~50 мб (окала 20000 позиций).
Во время работы программы, иногда, приходится обращаться к БД (только для чтения).

Формирую SQL запрос в ADOQuery, затем активирую его и считываю необходимые данные, затем деактивирую, формирую новый запрос и снова активирую.
Все это в цикле.

Так вот, допустим 500 объектам, которые таким образом получают данные из БД (1 запрос для 1 объекта), для этого требуется больше времени, чем например, загрузить и отобразить текстуру.

Если не обращаться к базе, то весь цикл отработает быстрее чем за секунду.
Если же обращаться к базе, то весь цикл отработает за 10-20 секунд.

Сам SQL запрос не очень большой:

SELECT [Прайс 1].Наценка, [Прайс скидок 1].Скидка, [All].* 
FROM [Прайс 1],[Прайс скидок 1], [All] 
WHERE ([Прайс 1].Код=[All].Код and [Прайс скидок 1].Код=[All].Код) and [All].[Тип] like "%В%" and [All].Положение like "%\9\%"
ORDER BY [All].Код;

Причем основное время занимает: QueryALL.Active:=True;
Даже если после активации ничего не считывать, и переходить к следующему элементу цикла, то время за которое он отработает - не на много сократится, в лучшем случае секунды на 2.

Вот я и подумал, может есть какая-нибудь возможность ускорить этот процесс?

Подскажите как быть, может сам SQL запрос как-нибудь оптимизировать или я что-то не совсем так делаю.
Заранее спасибо!

[Slym]

а так?

SELECT [Прайс 1].Наценка, [Прайс скидок 1].Скидка, [All].*
FROM [All]
LEFT JOIN [Прайс 1] ON [Прайс 1].Код=[All].Код
LEFT JOIN [Прайс скидок 1] ON [Прайс скидок 1].Код=[All].Код
WHERE [All].[Тип] like "%В%" and [All].Положение like "%\9\%"
ORDER BY [All].Код

[Аватар]

Формирую SQL запрос в ADOQuery, затем активирую его и считываю необходимые данные, затем деактивирую, формирую новый запрос и снова активирую.
Все это в цикле.

И это в цикле 500 раз? Переделай логику - вытащи один раз все нужное из базы. Не обязательно одним запросом, можно в разные ADOQuery двумя-тремя запросами. 50Мб не так уж много

[Serge_Bliznykov]

+1. я полностью, на 146% согласен с мнением Аватар!
Я хотел сказать тоже самое, но не мог сформулировать!

[ZBEP]

Аватар, Serge_Bliznykov, дело в том, что "величина" цикла тоже варьируется и нечто подобное я сделал, но если цикл более 500.
Для больших циклах - актуально, но когда необходимо получить разовую позицию, либо небольшой цикл, то из-за величины базы, предложенный Вами метод наоборот может замедлить работу (например если необходимые записи расположены где-то в конце, то пока дойдет до 20000 записи, 500 раз с ручной проверкой нужных данных - пройдут те же 15 секунд).

Еще заметил, что для старого, слабенького компа, разделитель типа получения данных в 500 объектов был более-менее оптимальным.
А для нового, этот параметр можно снизить скорее до 40-60.
Т.е. если менее 60 объектов, то используется метод описанный выше (который работает почти так же, одинаково долго на обоих машинах), иначе используется предложенный Вами метод.

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

О, а насчет этого:

Не обязательно одним запросом, можно в разные ADOQuery двумя-тремя запросами. 50Мб не так уж много

Как-то не подумал, спасибо, попробую.

Slym, сейчас проверю.

[eval]

лайки надо выбрасывать, по возможности, они тормозят

[Аватар]

Если напрямую в ADOQuery искать запись простым перебором или даже с помощью Locate, то может достаточно долго получиться. Но если использовать тот же ADOQuery в связке с ClientDataSet например и создать в нем нужные клиентские индексы, то поиск в ClientDataSet по FindKey по скорости практически не зависит от физического расположения информации в датасете

[ZBEP]

eval, знаю, но есть какая-нибудь альтернатива?
Просто в базе, есть столбцы, в которых вписан массив данных (типа: \1\23\645\..\n\ ), если не использовать лайки, то позже придется использовать "pos()", либо разбивать запись c помощью StringReplace в StringList и в цикле проверять наличие искомого номера.

pos - еще тормознутее, как и разбивка с перебором, в данном случае.

[ZBEP]

Аватар, про ClientDataSet, не знал, спасибо!
Буду пробовать!

[eval]

надо знать что к чему, может изначально (при внесении данных) в отдельные поля скидывать В и 9, а может еще чего. так только гадание