Key size too big for index IDX_SPISOK

← →
AVR (2003-03-19 16:02) [0]

Уважаемы мастера! Как побороть следующую проблему:
При создании индекса

Unsuccessful metadata update
key size too big for index IDX_SOISOK_IMYA
Statement: CREATE ASC INDEX IDX_SOISOK_IMYA ON SPISOK (S_IMYA)

Поле S_IMYA - Varchar(255).

В документации ничего по этому поводу не нашел.
Какой максимальный key size?
Как быть? (Очень нужен индекс по этому полю).

← →
Anatoly Podgoretsky (2003-03-19 16:53) [1]

У тебя наверно Collating Index тогда ограничение на длину ключя 84 символа (по три байта на символ). А насчет документации ты зря бочку катишь на дядьку Борланда, это хорошо описано в документации по ИБ

← →
Romkin (2003-03-19 16:56) [2]

НУ при PXW_CYRL понятно - на каждый символ 3 байта
Максимальная длина ключа - 256 байт
В строке 2-3 байта расходуется на ее длину

← →
AVR (2003-03-19 17:05) [3]

А что делать, если длинна поля 255?
Неужели это конец ?!

← →
Romkin (2003-03-19 17:23) [4]

Уменьшить длину поля, ессно

← →
AVR (2003-03-19 17:31) [5]

Понятно... Так и я могу.
Придётся так и сделать :(

Благодарю!

← →
Anatoly Podgoretsky (2003-03-19 19:14) [6]

Вообще надо подумать а нужны ли индексы для строковых полей свыше 30 символов

← →
AVR (2003-03-31 18:54) [7]

Бывает необходимость. Например имена документов могут быть довольно длинными, а искать без индексов слишком накладно (дисковое пространство дешевеет, а время - всегда деньги).
В этом случае конечно можно сохранять первые 30 символов в одном поле (специально для индексирования), а остальные или все - в другом. Но быстро проверить уникальность одним запросом трудно (хотя возможно).

← →
MsGuns (2003-03-31 19:05) [8]

>AVR © (31.03.03 18:54)
А что, документов миллионы ? Если несколько тысяч, то вполне справится с задачей запрос для контекстной выборки (LIKE), при этом индекс по полю в 200 символов может только замедлить (особенно если остальная чась записи существенно меньше). Или еще проще - в рез.НД сортируй по наименованиям, а на форму кинь контрол типа комбобокса, куда можно вводить символы. В событии OnChange запрос и включение в список только тех док-тов, у которых первые символы названия соотв-т Text комбобокса. Все эл-ты списка свяжи объектно с идентификаторами записей (ID), и делай FindFirst или Locate. Зачем для этого индексы ?????

← →
AVR (2003-03-31 20:09) [9]

>А что, документов миллионы ? Если несколько тысяч, то вполне >справится с задачей запрос для контекстной выборки (LIKE)
Хотите сказать, что IB расчитан на такое кол-во информации, что индексы вовсе не нужны. Или кроме поиска по имени документа с рабочего места пользователя других задачь нет? А перенос данных между системами при котором необходимо связывать (или просто сравнивать) документы по именам (десятки тысячь документов)? Или например выбор сортированного списка с использованием сложного запроса, при котором необходимо связывание дополнительных таблиц с уже отсортированной основной (десятки тысячь рез. записей).
Задачи бывают разные. Конечно все можно решить и с индексами на 30 символов, но это не всегда удобно.

← →
MsGuns (2003-03-31 20:18) [10]

>AVR © (31.03.03 20:09)

Использование реальных свойст объектов для идентификации, а тем более связки - это не просто грех, это - смертный грех для ЛЮБОЙ БД ! А если ДВА документа имеют одинаковые имена ? А если юзер через 2 недели увидел, что в ниаменовании допущена грамматическая ошибка, а у записи уже тыща "дочерних" записей ?

Да и вообще, использовать для связок или ключей длинные символьные поля - это просто дилетантизм высшей пробы !
И еще. А если документ (название) "не влазит" в 255 символов ? Что, в качестве ключей и связок использовать блобы (мемо)?

← →
AVR (2003-03-31 20:38) [11]

>Использование реальных свойст объектов для идентификации, а тем >более связки - это не просто грех, это - смертный грех для >ЛЮБОЙ БД !
Это в БД записи связаны числовыми идентификатрами, а вне её совсем не обязательно (см. выше "перенос данных между системами").

>А если ДВА документа имеют одинаковые имена ?
Вот это и приходится часто проверять.
Попробуйте проверьте уникальность без индекса.

>Да и вообще, использовать для связок или ключей длинные >символьные поля - это просто дилетантизм высшей пробы !
См.выше.
Кроме того использование реальных свойств объектов в большинстве случаев - единственный способ решения многих проблем при интегрировании нескольких локальных систем в одну (имеется ввиду межсистемные интерфейсы, а не сливание и хранение данных в одной БД).

← →
MsGuns (2003-03-31 20:45) [12]

>AVR © (31.03.03 20:38)
>Попробуйте проверьте уникальность без индекса.

Ну для этого как раз индексы и не нужны: поиск ОДНОЙ записи (при проверке на уникальность вставляемой) даже на сотнях тысяч записей "летает".

>Кроме того использование реальных свойств объектов в >большинстве случаев - единственный способ решения многих >проблем при интегрировании нескольких локальных систем в одну

Притив этого трудно возразить, тем более не зная сути конкретной проблемы. Поэтому не возражаю ;))

← →
Sergey Masloff (2003-03-31 22:50) [13]

AVR © (31.03.03 20:38)
>Использование реальных свойст объектов для идентификации, а тем >более связки - это не просто грех, это - смертный грех для >ЛЮБОЙ БД !
Это в БД записи связаны числовыми идентификатрами, а вне её совсем не обязательно (см. выше "перенос данных между системами").

Я использовал суррогатные ключи с типом DOUBLE (вообще-то NUMERIC(m,n)). То что после десятичного разделителя - уникальный код "узла" распределенной системы. Вопреки гневным возгласам система работает очень неплохо. Проблем с производительностью (да и с остальным) не наблюдается...

Key size too big for index IDX_SPISOK_IMYA Найти похожие ветки