Ответ.

В SQL при массовых изменениях часто требуется реализовать сценарий «всё или ничего» — либо все изменения проходят, либо откатываются при любой ошибке. Такой подход достигается использованием транзакций. Хранимая процедура должна явно стартовать транзакцию (BEGIN TRANSACTION), обернуть соответствующие операции, обрабатывать ошибки, и в случае сбоя выполнять ROLLBACK, иначе — COMMIT.

Нужно не забывать о корректной обработке ошибок через конструкции вроде TRY...CATCH (SQL Server) или EXCEPTION (PostgreSQL).

Пример для SQL Server:

CREATE PROCEDURE MassUpdate
AS
BEGIN
    BEGIN TRY
        BEGIN TRANSACTION;

        UPDATE Orders SET Status = 'Processed' WHERE Status = 'Pending';
        UPDATE Inventory SET Stock = Stock - 1 WHERE ProductID IN (SELECT ProductID FROM Orders WHERE Status = 'Processed');

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        ROLLBACK TRANSACTION;
        -- Логирование ошибки
        THROW;
    END CATCH
END

Вопрос с подвохом.

Вопрос: Достаточно ли использовать только BEGIN TRANSACTION и COMMIT, чтобы гарантировать корректный откат изменений при ошибках во всех поддерживаемых СУБД?

Ответ: Нет, сама по себе транзакция не ловит исключения. Необходимо использовать обработчики (TRY...CATCH или аналогичные), чтобы отловить ошибку и явно вызвать ROLLBACK. В некоторых СУБД (например, MySQL с autocommit) также может понадобиться дополнительная настройка.

Пример неправильного кода (SQL Server):

BEGIN TRANSACTION;
UPDATE Users SET Name = 'Ivan' WHERE ID = 1;
UPDATE Orders SET Amount = Amount/0 WHERE UserID = 1; -- Ошибка деления на 0
COMMIT TRANSACTION;

В этом случае, если возникнет ошибка — транзакция так и останется открытой, а изменения в первой таблице могут сохраниться.

История

На проекте интернет-магазина забыли обработку ошибок в транзакциях, что привело к частичной потере связанных данных: если при обновлении заказа возникала проблема с обновлением стока, только часть изменений откатывалась, нарушая целостность информации.

История

В проекте BI-аналитики внедрили массовый перерасчёт отчётов через процедуру без явного контроля транзакций и ловли ошибок. Итог: часть отчетов обновилась, другая — нет. Финальные данные оказались неконсистентны, так как аварийные ситуации не приводили к атомарному откату.

История

В одной компании ошибочно полагались на autocommit в MySQL, не выставив режим транзакций для крупных операций. При сбое сервера часть данных была уже записана, другая — нет, что вызвало долгие восстановительные работы и потерю части заказов.