Прихожане! Приведенный трактат был мною отправлен г-ну А. Ковязину и по ЕГО просьбе выложен на этот форум вместе с его ответом.\r
Сам я не хотел так много разглагольствовать и НЕ стремился обнародовать все это, так что извиняйте за большой объем текста!\r
Всех с Новым Годом!\r
\r
######################################################\r
\r
Добрый день, Алексей! \r
Поздравляю Вас с Новым Годом, желаю Вам здоровья, удачи во всех делах, и, конечно, скорейшего выпуска и стремительной распродажи\r
2-го (3-го и т.д.) тома "Мира IB" :)\r
\r
Если у Вас будет время, рассмотрите, плз, мой вопросик. Я его изложил довольно многосложно, поэтому не выкладываю на форум,\r
а то обвинят еще в "графоманстве".\r
\r
Моя проблема в следующем:\r
имеется большой список организаций и физ. лиц (т.н. "КОНТРАГЕНТОВ"), которые могут быть разделены на след. категории:\r
1) поставщики товаров; 2) розничные покупатели и заказчики; 3) оптовые покупатели; 4) субдилеры.\r
\r
Вместо четырех отдельных таблиц для каждой категории я создал одну с суррогатным ключем, обозначающим соответствующую категорию:\r
CREATE TABLE agents (\r
agtype SMALLINT NOT NULL, \r
agnumb INTEGER NOT NULL, \r
agname CHAR(60) NOT NULL\r
);\r
Создан также первичный ключ по полям (AGTYPE,AGNAME,AGNUMB) // обратите внимание на ПОРЯДОК полей!\r
\r
Задача в том, чтобы организовать для пользователя ввод с "инкрементным поиском" для любой выбранной им (юзером) категории, т.е.\r
при запросе, например, поставщиков (категория=1) сформировать в компоненте TIBQuery следующий запрос:\r
SELECT agname FROM agents \r
WHERE agtype=1 AND agname STARTING WITH \'<строка_которая_сейчас_в_поле_ввода>\'\r
ORDER BY agtype,agname ROWS 20;\r
\r
- и выводить результат в TDBGrid, чтобы юзер мог из них выбрать что-либо.\r
\r
Так вот, "зарегистрировано открытие" !! :)\r
1. При достаточно большом числе строк (я запихал туда из реальной БД около 40 тыс. записей) директива STARTING WITH ...\r
ведет себя очень "странно", тормоза такие, как при натуральном переборе! Просмотр анализа (в IB Expert\'e) выдает результат\r
в несколько десятков тысяч ИНДЕКСНЫХ поисков! Т.е. понятно, что IB сначала отбирает ВСЕ строки ТОЛЬКО ПО ПЕРВОМУ \r
условию (agtype=1), и только потом в них копается и отбирает записи по ВТОРОМУ условию (starting with ...)\r
2. Если директиву STARTING WITH заменить на оператор сравнения ">=", т.е.:\r
...\r
WHERE agtype=1 AND agname >= \'<ВЕДЕННАЯ_СТРОКА>\',\r
\r
то записи отбираются МГНОВЕННО, все работает прекрасно, за исключением одного: если в базе НЕТ строк, которые начинаются\r
с того, что сейчас введено поле ввода, то на экране остается последний набор, ранее отвечавший этому условию.\r
\r
3. Если создать ключ по полям (AGNAME,AGTYPE,AGNUMB), то все будет работать нормально. Но мне такой ключ не подходит, т.к.\r
вместе с поставщиками, к примеру, будут лезть также сторонние покупатели, субдилеры и другие категории!\r
\r
Вопрос-1: действительно ли IB может "индексно" (БЕЗ ПЕРЕБОРА) искать только по ПЕРВОМУ полю в случае, когда индекс состоит\r
из нескольких полей?\r
Как в моем случае можно "быстро" определять, что для введенной строки в БД нет ни одной записи, которая бы начиналась с введенных \r
символов?\r
\r
Вопрос-2: как в аналогичной ситуации будет вести себя "жар-птаха" или наш "дятел" (прошу прощения, FB и Yaffil) ?\r
\r
Заранее Вам спасибо, что дочитали до конца, еще раз с Новым годом!\r
Буду весьма благодарен за ответ. Павел.\r
\r
P.S.\r
В нитке /topic/11507 я нашел Ваш отклик на вопрос, "похожий" в чём-то на мой.\r
Там Вы сказали про "скорострельность" директивы STARTING WITH ... для случая, когда юзер что-то вводит в поле и ему сразу\r
отображается набор строк из БД. К сожалению, мой пример показывает, что это НЕ срабатывает в описанном мною случае.\r
\r
P.P.S. \r
Где-то еще я читал про то, что IB выполняет bitmapping строк, подпадающих под каждое условие запроса в случае "сложного" условия\r
(разделенного AND / OR). Тогда почему он НЕ выполняет это при использовании оператора сравнения ">=" ?!\r
\r
######################################################\r
\r
Ответы г-на А. Ковязина:\r
\r
1. Необходимо взглянуть на план запроса, чтобы точно ответить в чем причина.\r
\r
2. В Дятле многочисленные правки оптимизатора были\r
(http://www.interbase-world.com/modules.php?name=News&file=article&sid=15&mo\r
de=&order=0&thold=0) и обычно он выбирает планы лучше ИБ/ФБ. Проще всего\r
скачать и проверить :)\r
\r
В любом случае ИБ6.5 никак не лучше ФБ1.0 - там не попралвены многие баги\r
6.0, вроде того, что триггер before insert срабатывает раньше check.\r
\r
Если это не прихоть начальства, то лучше работать на последнем ФБ1.0.2.\r
А Дятла лучше приобретать все-таки после релиза...\r
\r
Из ИБ можно смотреть только на ИБ7, так как он совместим с будущим ИБ8,\r
который обещает много чего :)\r
Закладываться на ИБ6.5 не очень удачная идея, имхо.\r
\r
Ответы на P.S.:\r
============\r
>"...Там Вы сказали про "скорострельность" директивы STARTING WITH ... для\r
случая, когда юзер что-то вводит в поле и ему сразу отображается набор строк из БД. К сожалению, мой пример показывает, что это\r
НЕ срабатывает в описанном мною случае."\r
\r
ОТВЕТ:\r
Так и есть - но должен быть индекс по полю, с которым есть Starting with.\r
Попробуйте создать три индекса по всем трем нужным полям.\r
Композитные индексы не слишком хороши в ИБ. Я лично очень редко ими\r
пользуюсь, хотя вроде есть любители...\r
\r
\r
>"...Где-то еще я читал про то, что IB выполняет bitmapping строк, подпадающих под каждое условие запроса в случае "сложного" условия (разделенного AND / OR)."\r
\r
ОТВЕТ:\r
В доке это написано :) Database Definition Guie, про индексы глава.\r
\r
>"...Тогда почему он НЕ выполняет это при использовании оператора сравнения ">=" ?!\r
\r
ОТВЕТ:\r
Там много оговорок, почему да как он это использует.\r
В моей практике частенько композитный индекс работал медленнее двух\r
отдельных.\r
\r
\r
WBR,\r
Alexey

Я ж ведь предупреджал, что "материала" будет много