Форум StopLinux

MSD SQL Server 2008, хотя это и неважно :-) Хотелось посмотреть различные варианты.

Мне было интересно, представит ли кто-нибудь 1 (один) запрос хоть под какой-нибудь сервер. Супер-мега-кул-программеров с миллиоами пользователей их творений на форуме хватает, а на простой вопрос ответа нету :-(

Что-то в ответе я не вижу даже SELECT'a :-)

Именно что там. В MSDN их ещё больше. :-)

И, кстати, как отреагируют те запросы при

А если 2, 7, 3, 4? Или 7, 2, 3,4.
Кстати, условие написал не совсем верно. Не первое, а минимальное значение.

Редактировался Maddoc (06-11-10 02:34:28)

select rnum as "пропущенное зн-е" from (select rownum as rnum, id from testid order by id) where rnum != id;

Не вернет 4, если у тебя ид будут 1 2 3 тк.к. всегда ровнам будет равен ид. Как я понял в задаче надо, чтобы в таком случае возвращалось 4.

В принципе мы еще один вариант подробно разобрали в ЛС. Если мэдок одобрит, сюда выложу.

Я поздравляю тебя с тем, что ты знаешь из математики N in Z! Дальнейшее развитие офтопа и срача в этой теме повлечет предупреждение.

А если цифры 5 6 7, то какое значение запрос выдаст?
В ссылке, которая приведена во втором сообщении, первый запрос как раз, по сути, этот. Только скан делает по i+1

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

Ну, вобщем, раз меддок бухает, то выложу что ле.

Решение без дурацких запросов: Дефрагментация индексов.
https://msdn.microsoft.com/en-us/library/ff650692.aspx

Решение с дурацким запросом:
Идея в том же поиске по ид+1. Фишка в чем, поиск с ид+1 катит, но не учитывает первые пустые поля (если числа. например 567). Для этого можно делать одну проверку на занятость ячейки с с ид=1. Если такая ячейка не занята, то сначала надо занять ее (минимальный, да). Если занята от нее уже само отсчитывается.

SELECT  TOP (1) CASE 
  WHEN (NOT EXISTS (SELECT id FROM  test AS t2 WHERE (t2.id = 1))) THEN 1 
  WHEN (NOT EXISTS (SELECT id FROM  test AS t2 WHERE (id = t1.id + 1))) THEN id + 1 
  END AS 'freeId'
FROM test AS t1
ORDER BY id

С точки зрения быстродействия, если есть ордер бай, МС БД может в любом случае перебирать  таблицу от начала до конца (до поиска дырок). Чтобы этого избежать можно использовать кластеред индексы. Тогда ордер бай идет по ним и, по идее, перебор будет идти только до дырки (топ(1) остаовит).
https://technet.microsoft.com/en-us/libr … 90639.aspx
Если верить описанию оптимайзера МС ДБ, NOT EXISTS (SELECT id FROM  test AS t2 WHERE (t2.id = 1)) будет проверена 1 раз.
Таким образом первый кейс  проверяет только первый же индекс. Второй кейс перебирает до первой дырки. Поэтому это, наверное, оптимально с точки зрения быстродействия. Но это в теории. На практике - я не специалист по МС БД. Профайлер в руки и смотреть))
Можно эту логику - проверить 1-й, искать с ид+1 реализовать просто с помощью IF, ELSE в запросе и не надеяться на правильную оптимизацию. Можно записать в виде 2-х запросов с юнион. 1-й из которых возвращает 1 или нуль. Будет ли быстрее работать на практике? - без понятия, не специалист.
Решение с ров набмером:
ROW_NUMBER()  не возвращает 4, если у тебя числа 1 2 3. Значит можно добавлять такой же(как в прошлом примере) проверочный запрос, только проверять последнее поле, а отсчитывать последнее поле по логике больнее, чем первое. К тому же МС СКЛ ROW_NUMBER() идет со своим сорт бай и, возможно, будет перелопачивать таблицу даже с кластеред индексами
Ссылка на проблему медленного ROW_NUMBER
https://weblogs.asp.net/eporter/archive/ … t-Set.aspx

Более дурацкие решения, которые рождались в процессе:

SELECT   TOP (1) id - 1 AS freeId FROM test AS t1
WHERE    (NOT EXISTS
                  (SELECT   id
                   FROM      test AS t2
                   WHERE    (id = t1.id - 1))) AND (id - 1 > 0)
UNION
SELECT   id + 1 AS freeId FROM test AS t1
WHERE   NOT EXISTS
                  (SELECT   id
                   FROM      test AS t2
                   WHERE    (id = t1.id + 1))
ORDER BY freeId

Например, если у тебя числа 5 6 8, этим запросом ты получишь 4 7 9. Т.е. если ты будешь брать первое значение этого запроса, ты будешь сначала заселять пустые места "к началу", а только потом все остальные. Будет ли такой запрос хорошо оптимизироваться по TOP(1) - не имею понятия, но предполагаю, что первое решение - лучше)))

Более громоздкие решения
Можно делать карты дырок, например, но к чему этот гемор?
Прицепить триггеры на инсерт и делет, которые будут вписывать и убирать "карту".