Всем привет!

Есть простейший непериодический независимый регистр сведений. Измерение только одно — "НомерПоПорядку", индексируется. Для каждой новой записи рассчитывается и присваивается по правилу МаксимальныйСуществующийНомер + 1.

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


http://prntscr.com/k0uhmr

Сделайте еще 1 РС, куда будете писать максимальный номер по порядку.

Думаю план будет идентичен.
Как минимум на оракле

(0) Однозначно 2-ой, но, возможно, SQL настолько мудр, что и первый.

Никаких срезов делать не надо.

вопрос, есть ли по этому полю индекс?

(4) Хароший вопрос, да, ERWINS?

(5) туплю

будут идентичны

(6) Предполагаешь или знаешь?

(7) ну так ведь индекс-то есть. правда непонятно, зачем автор делает автоинкремент вот таким вот небезопасным способом?

(8) а какой ещё способ есть в этих рамках?

(9) блокировать регистр пока текущий набор записей не отработает, например.
иначе, в интервал времени, пока предыдущий юзер получил номер, но еще не записал своё - кто-то тоже получит тот же номер и запишет поверх.

Я за вариант без сортировки, но в целом будет одинаково.

+(11) хотя бы из-за того что проц. подпрыгнет на сортировке

(12) Почитайте про кластерный индекс

(13) Такие регистры вроде без кластерного создаются? Или я ошибаюсь?

(0) Вопрос по-моему не стоит выеденного яйца. Будет одинаково. А если регистр вырастет настолько, что появится ощутимая разница, можно ведь переписать. Но гораздо раньше появится проблема (10)

(14) С кластерным

(13) а шо там читать.., сортированные данные или не сортированные будут возвращены..., думать не хочу, если есть возможность избежать сортировки, лучше избежать, для меня.

(14) [ОРРХ | ОРНР1 +] Измерение1 + [Измерение2 +...] (Кластерный)

В идеале, было бы неплохо, если бы текущий максимум можно было хранить в глобальной переменной сервера. В очень глобальной, такой, например, как блокировка сеанса.
то есть, первое обращение, допустим, инициализирует эту хрень, а дальше, из своего сеанса, мы можем этот счетчик инкрементить. Так, что все другие сеансы будут об этом знать. Но это фантастика, наверное.

(17) Это печально.

В идеале будет прочитана одна страница индекса. И всё. В неидеале - несколько.

Вот такие у нас 1Сники

(19) Слава тебе, Господи, что 1Совцы не проектируют SQL сервера!

(21) это прекрасно что это все, ну или почти все, понимают, но разве в (17) я об этом? Не думаю...

(22)а вот тут Вы правы

(24) Выбрать 600-ую страницу снизу из 600 страниц гораздо лучше, чем перебирать 600 страниц.
Но я думаю, что SQL достаточно умен, чтобы не перебирать 600 страниц в случае Максимум() а точно также выберет 600 страницу.
Просто с Сортировать это железно будет, а с Максимум - не уверен

(26) конечно лучше, в случае индекса, но если индекса нет. Это не в случае (0)

Можно сделать замер

(19) Поздравляю, ты почти изобрел нумератор.

(26) С Максимум точно так же ничего железного. Пути планировщика запросов неисповедимы.

(0)
http://risovach.ru/upload/2018/06/mem/freyd_180789277_orig_.jpg