|
|
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
В таблице имеется поле name C(254) Пытаюсь сделать индекс , получаю сообщение invalid key length методом проб выяснил что максимальная длина индекса может быть всего 120 символов. INDEX ON LEFT(name,120) TAG NAME Как обойти это ограничение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2006, 23:21 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
Никак. Это системное ограничение FoxPro. Точнее так: Если используется SET COLLATE TO MACHINE, то Длина ключа для файла IDX - до 100 символов Длина ключа для файла CDX - до 240 символов Если используется SET COLLATE отличный от MACHINE, то длина ключа уменьшается в 2 раза Для файлы IDX - до 50 символов Для файла CDX - до 120 символов Однако на практике, ключ, длиннее 50 символов используется крайне редко. Обычно в этом нет никакого смысла. Для FoxPro практичнее использовать не один составной индекс, ключ которых - это выражение из нескольких полей, а несколько простых, ключ которых - это значение одного поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2006, 02:00 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
Спасибо! Жаль, придется на другие СУБД переезжать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2006, 08:58 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
Hi Владимир! > Длина ключа для файла IDX - до 100 символов > Длина ключа для файла CDX - до 240 символов На самом деле играет роль не то idx это файл или cdx, а то компактный он (cdx всегда компактный) или "ординарный" - вот как раз idx и могут быть "ординарными", но могут и компактными. Кстати, по этой причине я везде поограничивал размер char полей 240 символами (не думаю что столь существенна разница между 254 и 240 чтобы заморачиваться на это). Правда есть ещё одно НО - если поле допускает NULL, то это "съедает" один байт в ключевом выражении (т.е. тогда нужно использовать CHAR(239) ) И ещё - я не вижу серьёзных причин использовать столь большие индексные ключи на постоянной основе - т.е. как временный индекс для выборки отображаемой в гриде (с целью упорядочения) - да, а как постоянный для таблицы... Обычно в больших текстовых полях используют поиск по "вхождению подстроки", а по "начальным символам", и тем более по "точному соответствию" - гораздо реже. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2006, 18:10 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
TuchaСпасибо! Жаль, придется на другие СУБД переезжать. А вы дамаете, что у других СУБД нет ограничений по длине ключа индекса?! Вы заблуждаетесь ! Например, у SQL Server 2000 это ограничение тоже есть - 900 байт. И вообще не понятно, зачем такой длинный ключ. При такой длины ключа большая часть приемуществ использование индекса может и не работать. С уважением, Алексей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2006, 19:55 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
Столкнулся с такой ситуацией, что необходимо в таблице отфильтровать по уникальным записям в этом поле C(254), а так как некоторые записи в этом поле отличаются друг от друга где-то на 200 -ом символе и больше, то такие записи под уникальный индекс не попадают, хотя и являются уникальными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 22:38 |
|
||
|
Ограничения индекса
|
|||
|---|---|---|---|
|
#18+
TuchaСтолкнулся с такой ситуацией, что необходимо в таблице отфильтровать по уникальным записям в этом поле C(254), а так как некоторые записи в этом поле отличаются друг от друга где-то на 200 -ом символе и больше, то такие записи под уникальный индекс не попадают, хотя и являются уникальными. А если сжать эти выражения? Или использовать хэш? И по нему уже проводить индексацию и быстрый поиск уникальных записей... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 23:46 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=33654101&tid=1591933]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
160ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 417ms |

| 0 / 0 |
