Уменьшить все значения в столбце после вставки сверху SQL
Before Inserting
Id Priority
1 . 1
2 . 2
3 . 3
After Inserting Id: 4, Priority 2
Id Priority
1 . 1
4 . 2
2 . 3
3 . 4
довольно новичок в postgres, и у меня есть таблица со столбцом с именем priority. этот столбец должен иметь уникальные значения, и если вы попытаетесь присвоить строке уже существующий приоритет, он просто вставит ее с этим приоритетом и уменьшит все приоритеты <= на единицу, чтобы учесть это.
есть ли термин для такого поведения? Я знаю, что это будет включать столбец с уникальными значениями, но есть ли какие-либо ограничения модели, которые я могу ввести, чтобы включить такое поведение? или мне нужно вручную кодировать алгоритм для этого и учитывать все крайние случаи.
Похоже, что существует ограничение модели ON CONFLICT, которое может обновить строку, имеющую то уникальное значение, которое вы пытаетесь вставить. Интересно, может ли это срабатывать последовательно? Вставить с приоритетом 3, приоритет 3 существует, обновить существующий приоритет 3 до приоритета 4, приоритет 4 существует, обновить существующий приоритет 4 до приоритета 5, приоритет 5 существует ...
Не уверен, насколько хорошо это будет каскадно, если у вас будет изменено более пары идентификаторов при вставке. Я дам ответ, который вычисляет приоритет на лету
спецификации требуют обновления / вставки только одного приоритета за раз. похоже, что каскадные триггеры предназначены для такого рода поведения, database-programmer.blogspot.com/2008/05/…, теперь просто чтобы выяснить, поддерживает ли sequelize это
Я имел в виду, что если бы у вас была база данных с приоритетом от 1 до 10001 и вы попытались вставить приоритет 2 ... будет ли модель конфликта эффективно ограничивать все 10 КБ? Я подозреваю, что это решение не будет хорошо масштабироваться и, вероятно, приведет к гигантскому циклу On Conflict.
Ответы 1
Я бы не стал хранить приоритет как собственное поле. Создайте таблицу как ID, Priority, Date_entered. Затем используйте:
Select ID, rank() over (order by priority, date_entered) as priority
...
Я подозреваю, что, поскольку ранг может меняться так часто, вычисление его на лету было бы предпочтительнее, чем попытки сохранить ранг и поддерживать его в актуальном состоянии.
редактировать: В этом есть логическая ошибка, которую я уже могу заметить ... если запись 4 была вставлена как приоритет 2 (так что база данных содержит 2 записи с приоритетом 2), действительно не было бы простого способа ввести идентификатор 5 между идентификатором 4 и 2 без изменения поля date_entered.
второе редактирование: Разрешение столбцу приоритета быть десятичным (вводится приоритет 2, затем вводится приоритет 2.5 и так далее), а затем использование функции rank () для преобразования этого значения в целое число позволит обойти это. Здесь нет красивого ответа, который я могу найти
Любопытно, есть ли на это более элегантный ответ, чем триггер после обновления вставки priority = priority + 1, где priority +> вставленный приоритет.