iBase.ru Forum

Использую FireBird 1.0. IB Еxpert позволяет создать индекс по полю типа Varchar, если только его размер не превышает 84 символа, то есть если я объявлю varchar(85), то по этому полю я уже не могу создать индекс. Индексирую я названия организаций. В списке есть организации, полное название которых больше 85 символов и сокращенное название использовать нельзя. Насколько я понимаю сортировку по названиям организаций мне придеться использовать довольно часто, следовательно индекс надо создать. Могу ли как-либо обойти это ограничение?

Помедитруй вот на какую тему: А действительно ли мне нужен collate на этом поле и так ли он мне нужен, что я иду на то, что укорачиваю с его помощью втрое максимальный размер индекса на этом поле? И если таки да, то а не пожертвовать ли мне дисковым пространством и не сделать ли мне один из таких финтов ушами:
- дублировать это поле без COLLATE для поисков по индексу (это если длина поля таки меньше 255).
- сделать втихую за кадром поле с сокращённым названием символов этак на 50, поиск по индексу на starting осуществлять по нему (юзер все равно заимеется вводить больше для поиска) и никому об этом не рассказывать.
- имхо самый геморный вариант - сделать поле с хешем названия, индексировать его и искать в дальнейшем по хешу.

Если всё это не устраивает - ждать выхода FB2.

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

Искренняя вера людей в быструю сортировку по индексу меня не перестает поражать. Или все поголовно борятся за скорость отображения первой записи в гриде?

dimitr писал(а):Человек хочет индекс для ускорения сортировки по наименованию.

А, ну да. Видать таки игра в бузину и дядьку заразна - он про сортировку, я про фильтрацию

dimitr писал(а): Если у него в базе не полмиллиона организаций, то IMHO проще забить болт на этот индекс и вместо этого выставить побольше SortMemUpperLimit.

Для классики, сам пониаешь, решение сомнительное. Да и для супера имхо - ну, первый сортировщик-счастливчик всё сожрал, остальные на диск.

dimitr писал(а): Искренняя вера людей в быструю сортировку по индексу меня не перестает поражать. Или все поголовно борятся за скорость отображения первой записи в гриде?

Ты знаешь, может не поголовно и не первую, но что большинство и первой страницы - почти уверен. И мульён - не мульён, а вот скажем

SNAME CHAR(30)
NAME CHAR(255)

select count(*) from store_names
СOUNT
===========
31123


select first 10 code from store_names order by sname
PLAN (STORE_NAMES ORDER NAMEX)
Elapsed time= 0.02 sec


select first 10 code from store_names order by sname||''
PLAN SORT ((STORE_NAMES NATURAL))
Elapsed time= 0.66 sec

select first 10 code from store_names order by name
PLAN SORT ((STORE_NAMES NATURAL))
Elapsed time= 1.97 sec