Индексный доступ

Интересует следущее - какой select по значению (или диапазону) выполнится быстрее по односегментными индексам при ASC или DESC (т.е. например, увеличится ли производительность при изменении forein key индексов с ASC на DESC), если все селекты выбирают только "новые" (т.е. только последнего "открытого периода") записи???

Объясните пожалусто попроще, а то ниасилил

wolverin

какой select по значению (или диапазону) выполнится быстрее по односегментными индексам при ASC или DESC, если все селекты выбирают только "новые" (т.е. только последнего "открытого периода") записи???

по DESC

wolverin

изменении forein key индексов с ASC на DESC

Не надо. Просто создай еще один индекс по DESC.

to Гаджимурадов Рустам
>>изменении forein key индексов с ASC на DESC
>Не надо. Просто создай еще один индекс по DESC.
Понимаете, хотелось бы увеличить скорость выборки при не изменении скорости
вставки.
А почему не надо? ведь это для чего-то сделано.

Posted via ActualForum NNTP Server 1.3

wolverin

Понимаете, хотелось бы увеличить скорость выборки при не изменении скорости вставки.

А это-то при чем? За планы боишься? Или думаешь, что один лишний индекс намного уменьшит скорость вставки? :)

wolverin

А почему не надо? ведь это для чего-то сделано.

Мда... Опять-25... Опера повотряется...

to Гаджимурадов Рустам
>А это-то при чем? За планы боишься? Или думаешь, что один лишний индекс намного
уменьшит скорость вставки?
Да планы они тут ни причем, им на тип индекса плевать. Форейнов много на таблице
и терзают меня смутные сомнения, что с DESC они работали бы быстрее. Сомнения
взялись с того что на 2 курсе препод по реляционным БД херовато объяснил (или я
так понял) механизм поиска по ним как последовательный перебор (на сколько я
понимаю это называется "однонаправленное сканирование индекса") до первой нужной
записи, и следовательно если это DESC-индекс то нужная запись найдется раньше
чем при АSC-индексе, нет???

>Мда... Опять-25... Опера повотряется...
Ну и что тут такого, если хочется узнать для каких целей сделана та или иная
вещь???

Posted via ActualForum NNTP Server 1.3

wolverin

Сомнения взялись с того что на 2 курсе препод по реляционным БД херовато объяснил (или я так понял) механизм поиска по ним как последовательный перебор (на сколько я понимаю это называется "однонаправленное сканирование индекса") до первой нужной записи, и следовательно если это DESC-индекс то нужная запись найдется раньше чем при АSC-индексе, нет???

Печально это. Неужели про B-деревья ничего препод вам не говорил?

wolverin

Форейнов много на таблице и терзают меня смутные сомнения, что с DESC они работали бы быстрее.

C какой стати? Все зависит от конкретных запросов.

wolverin

Сомнения взялись с того что на 2 курсе препод по реляционным БД херовато объяснил механизм поиска по ним как последовательный перебор (на сколько я понимаю это называется "однонаправленное сканирование индекса") до первой нужной записи, и следовательно если это DESC-индекс то нужная запись найдется раньше чем при АSC-индексе, нет???

В некотором смысле он прав: для недвунаправленных индексов (а это твой случай) это так.
Только вот фраза "последовательный перебор" применительно к индексу звучит как-то преступно,
"последовательный перебор" - это обычно natural.

wolverin

Ну и что тут такого, если хочется узнать для каких целей сделана та или иная вещь???

Я имел в виду "для чего-то". Был тут недавно один парниша,
который все никак не мог придумать где бы ему использовать массивы в FB -
потому что "они ведь для чего-то придуманы".

Лентяй

про B-деревья

Молчи, молчи... :) А то щас завалит вопросами :)

to Лентяй
>Печально это.
Да, честно говоря, тогда читалась основа - всего лишь файл-серверные СУБД на
примере FoxPro под DOS.

>Неужели про B-деревья ничего препод вам не говорил?
А вот про это можно поподробнее, а то фраза
"В Firebird индекс представляет собой страничное B+ дерево с префиксной
компрессией ключей"
мне, к сожалению, ни о чем не говорит.

Posted via ActualForum NNTP Server 1.3