Форум MySQL

есть таблица:
id field
1 45
2 33
3 84
4 23
5 20
6 93
7 15
8 74
9 21

можно ли одним стандартным sql-запросом, используя только одно значение id и одно значение field, обновить поле field так, чтобы получился результат в виде:
id field
1 45
2 33
3 102
4 103
5 104
6 105
7 106
8 107
9 108

А почему строка 1 45 осталась неизменной
а 9 21 превратилась каким-то чудом в 9 108
21--108
74--107
45--45

В этом есть какая то закономерность?

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

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

update table set field = field+1

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

в цикле это можно сделать, но тогда будет много запросов, а хотелось бы одним

извиняюсь что сразу не объяснил. надеюсь теперь понятно

у строк в таблице нет собственного порядка, кроме яавно заданного определенным полем.
Поэтому никаких field = field+1 нет и быть не может.
Может быть лишь update table set field = id -3 + 102 WHERE id BETWEEN 3 AND 9
если считать, что id - это поле, задающее порядок. Что обычно действительности не соответствует.

спасибо, всё ясно

суть проблемы подробнее
есть таблица

id pos
5 1
8 2
9 3
34 4
55 5
77 6
12 7
91 8
53 9

нужно удалить запись с id 9, 55, 91

id pos
5 1
8 2
34 4
77 6
12 7
53 9

каким образом оптимальнее всего сохранить порядок позиционирования чтобы было так

id pos
5 1
8 2
34 3
77 4
12 5
53 6

удаляя записи запросом

delete from `table` where id in(9, 55, 91)

без использования цикла?

проблема в том, что потребуется пересчитать заново столбец сортировки pos

я просто вижу решение как-то так:
1) найти минимальную позицию из всех удаленных записей min(pos)
2) извлечь все id записей, у которых pos>min(pos), отсортировав их ORDER BY pos ASC
3) обновить извлеченные записи в цикле (min(pos)++), на каждую запись по запросу

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

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

не хочется чтобы дырки возникли... хочется чтобы они все шли подряд

аргументы?
"Красиво выглядит" - не аргумент.
Поверьте, я на этом нажигался.

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

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

тогда ответьте пожалуйста на один вопрос
вот на ваш взгляд: 1) мой подход ненужный и нерациональный, чтобы заморачиваться и искать какие-то оптимальные решения или 2) имеет право на жизнь
?

я полагаю, что цеплять на эту непрерывность значений какой-либо функционал - порочно в принципе.
А если оная нужна лишь ради красоты, то нетрудно запустить раз в сутки скрипт, который пройдется по таблице и подчистит дырки. Вылизывать его (этот скрипт) до полного оптимума особого смысла нет, так как цель его вторична, а запускается он редко, и вследствие этого много каши все равно не съест.

PS. Хотя с помощью условной операции CASE наверное и возможно составить выражение кусочно-линейного преобразования, которое выкинет дырки за один запрос. Исключительно фарсу ради.


PPS. вот такой он мой взгляд, точнее голос - чисто совещательный.

спасибо , в общем-то всё предельно понятно :)
и отдельное спасибо за интересные мысли

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

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

для редактирования в ссылку суют id строки

я знаю. значение позиции будет не соответствовать