Добрый день.

Вопрос такой: есть ли смысл использовать указание направления сортировки в узлах индексов, если они (направления) - разные? Как они работают, я пока-что не заметил. Вот пример:

оба поля - unsigned int

Так вот, использовать такую сортировку не получается. Запрос типа
Не работает по индексу. ( Если вручную указать план - то индекс использоваться будет, но отбираться по нему будет только "половина" таблицы, а по второму полю (HighLimit) будет sequentially.

Никто не сталкивался с подобной проблемой? Если эта фича не работает - посоветуете что-нибудь другое для решения этой проблемы?

Сервер ASA 9.0.2
В таблице - 16 миллионов записей. Результаты запросов, как в примере - 2-4 записи. Данные в полях LowLimit и HighLimit не уникальные, но и сильно не повторяющиеся.

min/мах значение этих полей:

minlo,maxlo,minhi,maxhi
1048577,231735297,1048577,231740120


46283869

Спасибо большое за любые ответы.

MasterZiv
Смысл это делать есть для поддержки определенных ORDER BY.
Если у вас есть индекс, совпадающий с ORDER BY , то сервер
может выполнять запрос без сортировки, двигаясь по индексу.
Posted via ActualForum NNTP Server 1.4

Да, действительно, спасибо. Если пишу так:

То идет по "правильному" плану Scan DocLimits using index i_DocLimits_HiLo (all rows)

Но, что... Хоть в ORDER BY и можно, в фильтре - нельзя?

A.K. YuRockНо, что... Хоть в ORDER BY и можно, в фильтре - нельзя?
А как вы себе представляете применение этого индекса сразу для проверки ваших двух условий? это было бы возможно, если бы индекс позволял сразу выбрать непрерывный диапазон, записи в котором удовлетворяют обоим условиям, но в вашем случае это совсем не так.

Пусть у вас условие: a=<5 and b>=5

Индексированные по a asc, b desc данные выглядят так (удовлетворяющие условию данные выделены жирным):
Да, наверное Вы правы...

YuRockДа, наверное Вы правы...
Вот только как быть... :\

A.K.а в чем проблема? вот вы говорите, что обоим условиям обычно удовлетворяет 2-4 записи.
а каждому из условий по отдельности сколько удовлетворяет?
В среднем - половина записей.

antandДобрый день!
Думаю в варианте автора манипулированием индексами и планами не обойтись. Данных много, да и условия выборки исключают нормальное использование индексов для достижения приемлимой скорости.
Может подход в корне поменять? Перепроектировать базу немного?
Какая бизнес-логика преследуется в выборке, что храниться в таблице и т.д.?
Эх, да если б я ее проектировал...
Логика такая. LowLimit и HighLimit - это диапазон талонов. В каждом таком диапазоне - от 1 до 10 талонов примерно. Вот таких диапазонов - 16 млн. уже.

Ну, единственный выход пока-что я вижу - чтоб не менять логику работы проекта (он огромный и мне не нравится в него лазить :) ) - это создать доп. таблицу, и в нее триггером на INSERT в DocLimits добавлять все строки диапазона и Id записи диапазона. Ну и единоразово в нее все загнать, а затем - этот триггер работать будет. Таким образом можно будет нормальным запросом получить все диапазоны, в которые входит талон.
Правда, в этой таблице получится миллионов 100 записей :(

Но пока на ум ничего больше не пришло...

antandЕще подробнее можно бизнес-логику?
Начиная от описания талонов, диапазонов, их связь, как вставляются записи в таблицы, что нужно на выходе и т.д.

На выходе нужно получить все диапазоны, в которые входит данный талон.

Как добавляются данные в таблицу диапазонов - я не знаю (через документы как-то. Это сейчас не важно)

Так вот, я предлагаю (сейчас это делаю и попробую поюзать) сделать таблицу, в которую будут попадать "развернутые" диапазоны.

Т.е. Если в записи DocLimits такая запись:
Id LowLimit HighLimit
12 1000 1003

то в DocLimitsEx будет так:
Id DocLimitId TalonId
1 12 1000
2 12 1001
3 12 1002
4 12 1003

Вот. А в DocLimitsEx данные буду записывать триггерами на таблицу DocLimits. И все. В итоге необходимый список диапазонов талона можно будет получить очень просто.

Другое дело, что, как я уже заметил эксперементально, кол-во записей в этой таблице получилось 55 миллионов... Многовато, однако... Но, думаю, так и оставлю.

White Owl YuRockНа выходе нужно получить все диапазоны, в которые входит данный талон.

Как добавляются данные в таблицу диапазонов - я не знаю (через документы как-то. Это сейчас не важно)Вот как раз это сейчас и важно. Трудоемкое решение задачи это первый признак плохой постановки задачи. Займись изучением бизнес-логики.
Постановка этой задачи если и была, то лет 10 назад, когда я еще университет косил :)
Это сейчас действительно не важно. Мне нужно строить запросы на основе готовых данных. Откуда взялись эти данные - какая уже разница?

Если я потрачу несколько дней для того, чтобы в е. PowerBuilder'е найти место (местА), где делаются инсерты в первоначальную таблицу - мне это абсолютно не поможет. Через триггеры будет все-равно лучше, чем в момент добавления диапазона отдельно добавлять записи в новую таблицу, т.к. это просто глупо. Да и убрать диапазоны как таковые (упростить логику) - тоже не совсем оптимально - в DocLimits размер записи довольно большой... Да и боюсь я это делать, и лень :)

В общем-то, я уже все сделал. Размер базы вырос на 25%, зато во многих местах начало летать. Если кто хочет еще что посоветовать - пожалуйста. Пока-что я склоняюсь к тому, чтобы закончить на этом...

antandПримерно ясно. Но раз у Вас нет таблицы талонов, то я бы сделал немного по другому.
Ввел еще одну таблицу - талонов Talons. И связал бы ее с DocLimits через DocLimitsEx
При вставке в DocLimits проверял, есть ли в Talons талон из вставляемого диапазона.
Если нет добавлял бы запись в Talons.
А потом фиксировал новую связь талонов и диапазонов в DocLimitsEx
Да при чем тут Talons. Такая таблица, как раз, есть :)
Но толку от нее, в ней же не указан список диапазонов, в которые входит данный талон. В ней вообще TalonId - это ПК.
А новая в таблице - TalonId - не уникальное поле.

А связывать DocLimitsEx теперь, естественно, можно с чем угодно будет...

White OwlЕсть еще один метод. Добавь в таблицу вычислимое поле примерно так:
low_high char(20) compute(LowLimit || HighLimit)
а потом сделай индекс на это вычислимое поле. И ищи данные по нему.

Интересно. Попробую.

antand
Так вот с этого и надо было начинать.
В таком случае в DocLimitsEx можно оставить только DocLimitId и TalonId как первичный ключ
Тю, ну можно, конечно. Ну а что изменится? (в данной задаче)

antandДа ничего, с точки зрения бизнес-локиги.
Только база станет на 16 миллионов*(размер поля id ) поменьше.
Примерно конечно.
Ну это немного. А вот если в будущем понадобиться это Id - будет уже интересней :)

antandКстати без поля id в DocLimitsEx база будет не на 16 миллионов*(размер поля id ) поменьше, а на 16 миллионов*(размер поля id )*<среднее кол-во талонов в диапазоне>.
Автор пишет: "В каждом таком диапазоне - от 1 до 10 талонов примерно". Пусть ~ 5
Итого 80 миллионов*(размер поля id ). Опять же примерно.
И зачем спрашивается?
Ну не жалко мне 300 метров :)
А Id у записи должно быть всегда, я так думаю. Принципиально. Он в автообмене распределенки потом работать будет очень хорошо... Да и вообще - это неплохой стиль, когда у всех таблиц есть ПК... Ну, это мое мнение.

Не, не получается ничего с вычисляемыми полями. Но это, наверное, и не удивительно. Невозможно, наверное... Т.к. я даже теоретически (уже :)) не представляю, как такую выборку (как в первоначальном вопросе) по индексу выбрать...