Сравните поведение нескольких присваиваний в одном UPDATE: можно ли переносимо считать, что каждое следующее получает уже изменённое значение столбца?
Нет, переносимо считать присваивания последовательными нельзя. В обычной реляционной семантике выражения SET вычисляются относительно исходного состояния строки, поэтому порядок присваиваний не должен использоваться как механизм передачи промежуточных значений.
Отдельные СУБД могут иметь собственные правила, поэтому код, зависящий от последовательного применения присваиваний, становится непереносимым и потенциально ошибочным.
SQL создавался как декларативный язык: запрос описывает требуемый результат, а не пошаговый алгоритм его получения. Поэтому текстовый порядок выражений обычно не означает порядок выполнения, как это происходит в императивных языках.
Для UPDATE такой подход позволяет оптимизатору выбирать план выполнения, не меняя логический результат операции. Идея одновременного вычисления новых значений также устраняет зависимость результата от перестановки столбцов в списке SET.
Предположим, в одной строке нужно увеличить баланс и вычислить бонус как долю от нового баланса. Если разработчик ожидает последовательное выполнение присваиваний, он может получить разные результаты после перестановки выражений или при переносе запроса в другую СУБД.
Риск особенно велик при миграции между системами. Запрос может успешно выполняться, но незаметно рассчитывать бонус от старого значения в одной системе и от уже изменённого значения — в другой.
Безопасное переносимое правило таково: каждое выражение нового значения следует рассматривать как вычисленное из исходной строки, если документация конкретной СУБД явно не устанавливает иное. Нельзя полагаться на порядок столбцов в SET как на последовательность операций.
Например, при исходном балансе 100 в системах с одновременной семантикой результат будет таким: баланс станет 200, а бонус вычислится как 10 процентов от старого баланса, то есть 10.
Если требуется использовать именно новое значение, его нужно выразить явно через производную таблицу, CTE или повторение формулы — с учётом синтаксиса целевой СУБД. Например, можно отдельно вычислить целевой баланс, а затем использовать это значение и для обновления баланса, и для бонуса.
Некоторые СУБД документируют особые правила. В частности, для одних вариантов UPDATE порядок присваиваний может иметь значение, тогда как другие системы сохраняют значения исходной строки для всех выражений. Поэтому при написании переносимого SQL следует избегать зависимости от таких различий и проверять документацию конкретной СУБД.
Компромисс между повторением формулы и явным подзапросом зависит от задачи. Повторение проще, но при сложной формуле повышает риск расхождения; отдельное вычисление лучше показывает намерение, но может потребовать диалектного синтаксиса.
В сервисе начисления бонусов разработчик обновлял баланс и бонус одним UPDATE. В тестовой СУБД бонус рассчитывался от уже увеличенного баланса, а после перехода на другую СУБД — от исходного. Ошибка не вызывала исключений, но приводила к систематически неверным начислениям.
Рассматривались два варианта. Первый — оставить порядок присваиваний и закрепить его тестом; это было просто, но зависело от диалекта и не защищало от изменений запроса. Второй — явно вычислять новый баланс в отдельном наборе данных и использовать его как источник для обоих присваиваний; решение сложнее, зато фиксировало нужную семантику.
Выбрали второй вариант и добавили тесты с исходными значениями, равными нулю, малому и большому балансу. В результате расчет стал одинаковым при перестановке столбцов и при выполнении в целевой СУБД.
Меняет ли перестановка выражений SET результат в стандартном SQL?
В переносимом коде перестановка не должна менять смысл: выражения рассматриваются относительно исходного состояния строки. Если перестановка меняет результат, это уже зависимость от конкретного диалекта или от недокументированного поведения, на которое нельзя опираться.
Можно ли использовать значение одного обновляемого столбца для вычисления другого?
Можно ссылаться на столбец в выражении, но это обычно означает обращение к его исходному значению, а не к результату соседнего присваивания. Если требуется промежуточный результат, его следует вычислить явно в подзапросе, CTE или повторить формулу.
Почему SQL не обязан выполнять присваивания слева направо?
UPDATE описывает итоговое состояние строки, а не последовательность команд. Такая модель оставляет оптимизатору свободу изменять физический план и не связывает корректность запроса с текстовым порядком элементов SET. Конкретная СУБД может предоставить иное расширение, но тогда это становится особенностью диалекта, которую нужно явно учитывать.