Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Key size too big for index IDX_SPISOK_IMYA [D6, IB6.x]

AVR © (2003-03-19 16:02:00)
Уважаемы мастера! Как побороть следующую проблему:
При создании индекса

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?
Как быть? (Очень нужен индекс по этому полю).

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

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

MsGuns (2003-03-31 20:45:00) [2]
>AVR © (31.03.03 20:38)
>Попробуйте проверьте уникальность без индекса.

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

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

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

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

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

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

MsGuns (2003-03-31 20:18:00) [4]
>AVR © (31.03.03 20:09)

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

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

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

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

AVR (2003-03-31 18:54:00) [7]
Бывает необходимость. Например имена документов могут быть довольно длинными, а искать без индексов слишком накладно (дисковое пространство дешевеет, а время - всегда деньги).
В этом случае конечно можно сохранять первые 30 символов в одном поле (специально для индексирования), а остальные или все - в другом. Но быстро проверить уникальность одним запросом трудно (хотя возможно).

Anatoly Podgoretsky (2003-03-19 19:14:00) [8]
Вообще надо подумать а нужны ли индексы для строковых полей свыше 30 символов

AVR (2003-03-19 17:31:00) [9]
Понятно... Так и я могу.
Придётся так и сделать :(

Благодарю!

Romkin (2003-03-19 17:23:00) [10]
Уменьшить длину поля, ессно

AVR (2003-03-19 17:05:00) [11]
А что делать, если длинна поля 255?
Неужели это конец ?!

Romkin (2003-03-19 16:56:00) [12]
НУ при PXW_CYRL понятно - на каждый символ 3 байта
Максимальная длина ключа - 256 байт
В строке 2-3 байта расходуется на ее длину

Anatoly Podgoretsky (2003-03-19 16:53:00) [13]
У тебя наверно Collating Index тогда ограничение на длину ключя 84 символа (по три байта на символ). А насчет документации ты зря бочку катишь на дядьку Борланда, это хорошо описано в документации по ИБ

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »