Reflow INT UNSIGNED Series

Question

У меня есть таблица ссылок BoxPeg, которая связывает серию Pegs с 1 Box.

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

Итак, у нас есть столбец INT UNSIGNED, называемый «position» в таблице BoxPeg.

Каждый раз, когда кто-то добавляет Peg к коробке, мы делаем это:

UPDATE BoxPeg SET position = position+1 WHERE box = '{BOXID}' AND position >= {NEWPEGPOSITION}; 
INSERT INTO BoxPeg(box, peg, position) VALUES('{BOXID}', '{PEGID}', {NEWPEGPOSITION}); 

Это прекрасно работает, пока клиент каким-то образом не переходит в новое положение колышек, что это слишком большой:

before: 
0 
1 
2 
3 

after insert 9 
0 
1 
2 
3 
9 

I знайте, что я могу получить MAX (позицию) WHERE box = '{BOXID}' в отдельном SQL-заявлении перед этими двумя строками и внести корректировку в новую позицию привязки на основе этого, но я бы хотел просто перепланировать всю серию в один снимок ПОСЛЕ Вставки. Таким образом, я на 100% уверен, что в каждой серии нет пробелов от начала до конца.

Как выглядит это ОБНОВЛЕНИЕ?

Рассмотрим такую ​​ситуацию:

before: 
0 
2 
5 
8 

after insert 5 
0 
2 
5 
6 
9 

after reflow 
0 
1 
2 
3 
4 

Answer 1

Вы можете оплавления строки, как это:

UPDATE BoxPeg bp 
INNER JOIN (
    SELECT *, @n := @n + 1 AS newpos 
    FROM BoxPeg, (SELECT @n := -1) x 
    WHERE box = '{BOXID}' 
    ORDER BY position 
) s 
ON bp.box = s.box 
AND bp.peg = s.peg 
SET bp.position = s.newpos 
WHERE bp.position <> s.newpos 
; 

подвыборки использует переменную для вычисления новых значений position для подмножества определенной конкретной {BOXID}. Затем оператор UPDATE присоединяет подзаголовок к BoxPeg и обновляет совпадающие строки с новыми значениями. (Таким образом, при присоединении к BoxPeg подзаголовок также действует как фильтр, ограничивая обновленные строки теми, которые принадлежат данному поле.)

Демонстрационная версия SQL Fiddle для этого запроса is available.

Обратите внимание, что если столбец position был частью уникального ограничения, этот метод might not always work. Хотя новые значения, которые генерирует этот запрос, уникальны, MySQL, по-видимому, оценивает уникальные ограничения во время обновления, а не в конце выполнения инструкции. Таким образом, в зависимости от порядка, в котором строки будут обновляться, запрос может завершиться неудачно, если строка получает значение, идентичное значению в другой, еще не обновленной строке.