Форум MySQL

Доброго времени суток!

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

Менеджер магазина хочет иметь возможность расставлять товары в том порядке, как ему хочется. Это в CMS реализовано следующим образом:
каждый объект каталога (группа, подгруппа, конкретный товар) кроме своего уникального id имеют еще и номер положения в выдаче. Этот номер уникален в пределах определенной группы, но в целом по базе он может повторяться неоднократно. Система работает, если надо переставить товар пошагово - на каждом клике он обменивается позицией с рядом стоящим.

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

Но сейчас количество товаров увеличилось, и гнать кнопочками товар на 40 позиций - уже менеджера стало утомлять. Попросили сделать вариант перемещения не по одной позиции, а более "быстрый".

И вот вопрос:
Как с минимальными затратами производительности сервера переписать значительную часть таблицы?
Ведь если мне, условно говоря, надо перекинуть продукт с позиции 40 на позицию 5 - то для всех продуктов с 5-й по 39-ю позиции надо переписать их код позиции, сместив на 1, а в образовавшееся 5-е место поставить перемещаемый продукт.

Что можно придумать?
Я пока придумал только вынести столбец кода позиции в отдельную таблицу, чтобы переписывать, по крайней мере, было меньше столбцов в каждой строке. Немного это поможет, но решение больше на костыль похоже, ИМХО.. хотелось бы чего-то получше.

мы делали так - порядок определяется дробным числом. сначала всем товарам присваивается
целое число в качестве его позиции в списке. если понадобится вставить еще один товар (или
переставить уже существующий), например, между 2-м и 3-м. ему дается порядок 2.5. если вам
мало 99 позиций, которые можно впихнуть между 2.00 и 3.00, сделайте три знака после запятой.

как вариант, интересное решение :)

но, правда, все равно тут есть как минимум парочка минусов..
- самый первый номер.. он когда-то же дойдет до минимума, от которого отнимать будет уже нечего
- наличие "дырок" в перечне. мы просто меняем шаг, а с тем же успехом можно было бы писать 100,200,300... потом по мере необходимости использовать 110 и 290, потом 99 и 301 ну и т.п.

В общем, на тестовом примере вида

$sql=" UPDATE LOW_PRIORITY shopmap_positions SET position=(position+1) WHERE ((position>=2) AND (position<5)) "; $res=mysql_query($sql)     or die(print_mysql_error($sql));

(промежуточные настройки я опустил тут) для 19 записей время выполнения что-то вроде 0.01187801361084 s. Я думаю, даже если записей будет 2000, это примерно в 100раз больше - получается чуть больше секунды; подождет пользователь... :)

ну и до кучи, чтоб уж не быть голословным:

Elapsed time: 0.11853003501892sec., number of affected rows: 319

это данные с "боевого" сервера, снятые только что.