回答。

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を使用するだけで、すべてのサポートされているDBMSで正しく変更をロールバックすることを保証できますか？

回答: いいえ、トランザクション自体は例外をキャッチしません。エラーをキャッチしてROLLBACKを明示的に呼び出すためには、ハンドラー（TRY...CATCHまたは類似のもの）を使用する必要があります。一部のDBMS（例：autocommitのMySQLなど）では、追加の設定が必要になる場合もあります。

誤ったコードの例（SQL Server）：

BEGIN TRANSACTION;
UPDATE Users SET Name = 'Ivan' WHERE ID = 1;
UPDATE Orders SET Amount = Amount/0 WHERE UserID = 1; -- ゼロでの除算エラー
COMMIT TRANSACTION;

この場合、エラーが発生するとトランザクションはオープンのままとなり、最初のテーブルの変更が保存される可能性があります。

物語

インターネットショップのプロジェクトでは、トランザクション内のエラー処理を忘れたため、関連データが部分的に失われる結果となりました。注文の更新中に在庫の更新に問題が発生した場合、一部の変更のみがロールバックされ、情報の整合性が損なわれました。

物語

BI分析のプロジェクトでは、トランザクションの明示的な制御とエラーキャッチなしでストアドプロシージャを使用してレポートを一括再計算しました。その結果、一部のレポートが更新され、他は更新されませんでした。最終データは整合性がなく、緊急事態が原子ロールバックを引き起こしませんでした。

物語

ある会社では、大規模な操作のトランザクションモードを設定せずにMySQLのautocommitを過信しました。サーバー障害が発生した際、一部のデータはすでに記録されており、他は記録されていませんでした。その結果、長い復旧作業と注文の一部の喪失を引き起こしました。