Индексирование VARCHAR

Добрый день!
Прочитал фак, так ничего не понял.
Какова максимальная длина поля varchar, которое можно проиндексировать?
Необходимо в этом поле хранить полный путь к файлу,
и осуществлять быстрый поиск.
Сервер - firebird embedded 1.5.3

buBBle

Какова максимальная длина поля varchar, которое можно проиндексировать?

Цифры не помню - а доке или факе посмотри, а смысл такой:
Если collate нету - то один символ занимает 1 байт, а байтов таких может быть до 168 кажется. Если у поля (или у домена) указан collate - то в 2 раза меньше. Если я все правильно путаю.
[/quot]

buBBle

Необходимо в этом поле хранить полный путь к файлу, и осуществлять быстрый поиск.

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

посчитать по твоему полю хэш и индекс строить по хэшу. Искать соответственно - тоже.

искать по индексу только по N первым символам, далее - натуралом. Тут понадобится либо интекс по выражению (есть в Ya, по FB не скажу) либо делать спец. поле куда выкусывать часть пути. Не очень-то оптимально по размеру БД, хотя зависит от задачи - во многих можно на размер забить.

радикальный вариант - пути писать не в строчку а разложить на составляющие и построить дерево. Искать соответственно по дереву.

ну и если не *NIX имеет смысл в доп поле сразу приводить в UPPER

fraks

радикальный вариант - пути писать не в строчку а разложить на составляющие и построить дерево. Искать соответственно по дереву.

Не радикальный, а мудрый!

Вот только не пойму - зачем в БД моделировать файловую систему?
Это я про постановку задачи в целом.

тынц не знаю, но вот кусок:

"Мир Interbase"

Как устроены способы сортировки? В COLLATION ORDERS строится дополнительная таблица пересортировки, определяющая порядок (условный вес) символов при сортировке. И в этой таблице для представления порядка символа может использоваться несколько байтов (2 или 3, например). В частности, в COLLATION ORDER WIN1251 используется 1 байт для представления символа и его порядка, а в опциональной PWX_CYRL - целых 3 байта! Размер представления веса символа в таблице порядка сортировки имеет значение при использовании индексов по полям символьных типов данных. Дело в то, что в индексе хранятся не исходные символьные строки, а ключи, полученные из строки на основе таблицы сортировки. Размер ключа может быть больше размера исходной строки: так, для порядка сортировки PXW_CYRL размер ключа может быть больше максимум в 3 раза, чем исходная строка. InterBase использует максимальный коэффициент для ограничения размера индекса по символьным полям. Таким образом, при максимальном размере индекса 254 байта вы не сможете создать индекс по полю с длиной более 254 div 3 = 84 символа Поэтому использование COLLATION ORDER может оказаться вещью, требующей достаточно многих ресурсов.

мда...
А если не индексировать?
у меня в таблице предполагается не более пары тысяч записей.
Насколько долгим будет поиск?
Помнится мне, что в NTFS максимальная длина имени файла-256
а какова максимальная длина полного пути?
Какую длину поля выбрать?

Если речь об однобайтовой кодировке и индекс используется только для поиска, то можно проиндексировать 253 символа. Триггером поле приводить к верхнему регистру. В виндах MAX_PATH определен как 260, так что есть некоторый риск не уложиться. Если это неприемлемо, тогда лучше индексировать обрезок строки (250 символов, например) или хеш, как тут уже предлагали.

> А если не индексировать?
> у меня в таблице предполагается не более пары тысяч записей.
> Насколько долгим будет поиск?

Детский размер, если для обработки одиночных запросов (тетя ищет определенный файл/папку) - то можно не индексировать.

Posted via ActualForum NNTP Server 1.3