есть таблица с абонентами на данный момент там 600 000 записей эта цифра будет рости постоянно, есть поле ЛС поставщика услуг написан запрос который ищит дырки в последовательности ЛС ПУ т.е.  идёт так

10000001 (поле варчар2)
10000002
10000233

запрос ищет дырку и вернёт значение 10000003, при малой нагрузки на сервак запрос отрабатывает за 2,5 сек надо быстрее  кто нибуть может подсказать как это сделать? вот запрос:

а ведь это еще не конец... 

если вы не можете убедить заказчика в абсурдности задачи и  не соответствии профита от непрерывной нумерации издержкам на ее реализацию, введите систему резерирования номеров лицевых счетов. Сформируйте табличку, которую заблаговременно наполните непрерывными номерами на десятки лет вперед, и устанавливайте статус номеру - занятый, свободный. Первый попавшийся свободный будет очень быстро выбираться по индексу.

Предлженая вами реализация - полная ж. Руки туда совать не приятно.

  

ziga, реализация действительно ...
Поиск первой свободной дырки (если мы говорим о БД), гораздо проще, например как-то так:

Deniz, ты забыл, что у него ещё эти ИДы хранятся как СТРОКИ...

еще в случае ненахождения дыры он берет максимальную строку и прибавляет к ней единицу   

еще абсурда добавляет то, что оракл - версионик и не блокирует по чтению, потому появляется возможность что дважды будет возвращен один и тот же айдишник. А т.к. вопрос достаточно тормозной, получается что это не просто возможно а весьма вероятно.

это я потом увидел, но привести к инту наверное можно, хотя ...

ziga, и опять поднимается вопрос о целесообразности поиска этих "дырок".

суть в том что должна быть возможность ввести номер руками и получить автоматом причём минимальное значение, по поводу таблички идея интересная, попробую продвинуть её

 
ж. не ж. а отрабатывает быстрее Вашего в 2 раза.



это не ID а строка Лицевого счёта, ID отдельный и они никак не связаны

Надо буйт побаловатсья. Думается мне, на действительно больших объемах hash join сделает window srot.... Однако ж были случаи, когда подобные мои предположения были развенчаны практикой.

Пиши функцию. Внутри - курсор. Думаю, быстрее получится.
Приблизительный код (без намёка на соблюдение синтаксиса)


Добавлено через 2 минуты и 40 секунд
PS. Надеюсь, поле индексировано?

конечно 

функция я думаю не вариант, а если нет дыр будет фечить все 600 000 записе (на данный момент)

Если и индексировано, то сортироваться надо по числовому представлению значения, иначе будет фейл. А это делает невозмжным использование индекса (если это не FBI)

Впрочем, решение ТС тоже не лишено этого недостатка.   

Найти решение, оптимальное при любых начальных условиях - нереально имхо. 
Прогнозируемое количество записей к фетчу и будет ли вообще вероятным такой пакостный исход - зависит от идеологии заполнения и хранения поля. Надо к чему-то привязываться...


Сабо самой... я же только идею пишу.
Впрочем, если длина поля фиксирована, и используется выравнивание вправо - фейла не будет.

Это сообщение отредактировал(а) Akina - 2.2.2011, 18:19

так в Вашем запросе есть доп. ограничение x not like '%666%'.
Может его добавить?

это всего лиш исключение номеров типа 10006660 суеверные, боятся числа 666