У меня есть страница, которая содержит много элементов, и ее можно переупорядочить путем перетаскивания, изменив столбец этого элемента с именем order (целое число). Для заказа на этой странице я делаю что-то вроде ORDER BY `order` ASC.
Процесс работает так (во время перетаскивания):
- Определение значения
order из целевого элемента (отброшено в);
- Обновить значение
order исходного элемента так же, как целевого элемента;
- Увеличить значение
order целевого предмета на единицу;
- Запросить, если другой элемент на столе имеет тот же
order, что и целевой элемент;
- Если true, увеличьте
order этого предмета на единицу;
- Повторять шаг 5 до тех пор, пока не будет элементов с таким же значением
order;
В конце процесса исходный элемент останется поверх целевого элемента.
Проблема этого процесса заключается в том, что он запускает 2 обновления + N раз (1 запрос и 1 обновление), в зависимости от того, насколько порядок будет конфликтовать после первоначального обновления. Так, например, в таблице с 1.000.000 элементов с заказом от 1 до 1.000.000, если я переместу элемент с порядком от 1 до 5, он выполнит почти два миллиона запросов.
Мое текущее решение - использовать order в качестве числа с плавающей или двойной. Затем, когда я вставляю значение в таблицу, я устанавливаю order равным id элемента.
Тогда процесс работает так:
- Определите значение
order из целевого элемента (отброшено в) - например. 503;
- Запросите первый элемент, у которого
order сразу ниже, чем order целевого элемента - например, 502;
- Обновите значение
order исходного элемента до avg обоих значений - например, 502,5;
Он будет работать нормально, но с большим количеством данных он будет конфликтовать в какой-то момент, и будет трудно идентифицировать или исправить этот конфликт.
Мой вопрос таков: Есть ли более надежный и быстрый метод, позволяющий обрабатывать элементы на столе, которые могут работать лучше, чем столбец с плавающей точкой?