Odpowiedź.

W SQL podczas masowych modyfikacji często wymaga się wdrożenia scenariusza „wszystko albo nic” — albo wszystkie zmiany zostają zatwierdzone, albo są wycofywane w przypadku jakiegokolwiek błędu. Takie podejście osiąga się poprzez wykorzystanie transakcji. Procedura składowana powinna wyraźnie rozpocząć transakcję (BEGIN TRANSACTION), objąć odpowiednie operacje, obsługiwać błędy, a w przypadku awarii wykonać ROLLBACK, w przeciwnym razie — COMMIT.

Należy pamiętać o prawidłowej obsłudze błędów za pomocą konstrukcji takich jak TRY...CATCH (SQL Server) lub EXCEPTION (PostgreSQL).

Przykład dla 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;
        -- Rejestrowanie błędu
        THROW;
    END CATCH
END

Pytanie z podstępem.

Pytanie: Czy wystarczy użyć tylko BEGIN TRANSACTION i COMMIT, aby zapewnić prawidłowe wycofywanie zmian przy błędach we wszystkich obsługiwanych DBMS?

Odpowiedź: Nie, sama transakcja nie wychwytuje wyjątków. Należy użyć obsługi błędów (TRY...CATCH lub podobne), aby złapać błąd i wyraźnie wywołać ROLLBACK. W niektórych DBMS (np. MySQL z autocommit) może być również potrzebna dodatkowa konfiguracja.

Przykład błędnego kodu (SQL Server):

BEGIN TRANSACTION;
UPDATE Users SET Name = 'Ivan' WHERE ID = 1;
UPDATE Orders SET Amount = Amount/0 WHERE UserID = 1; -- Błąd dzielenia przez 0
COMMIT TRANSACTION;

W tym przypadku, jeśli wystąpi błąd — transakcja pozostanie otwarta, a zmiany w pierwszej tabeli mogą zostać zapisane.

Historia

W projekcie sklepu internetowego zapomniano o obsłudze błędów w transakcjach, co prowadziło do częściowej utraty powiązanych danych: jeśli przy aktualizacji zamówienia wystąpił problem z aktualizacją stanu magazynu, tylko część zmian była wycofywana, co naruszało integralność informacji.

Historia

W projekcie analityki BI wdrożono masowe przeliczenie raportów za pomocą procedury bez wyraźnej kontroli transakcji i wychwytywania błędów. Efekt: część raportów została zaktualizowana, inna — nie. Ostateczne dane okazały się niespójne, ponieważ sytuacje kryzysowe nie prowadziły do atomowego wycofania.

Historia

W jednej firmie błędnie polegano na autocommit w MySQL, nie ustawiając trybu transakcji dla dużych operacji. W przypadku awarii serwera część danych była już zapisana, a inna — nie, co spowodowało długie prace naprawcze i utratę części zamówień.

Wyjaśnij podejścia do obsługi błędów i wycofywania zmian podczas masowych modyfikacji danych za pomocą procedur składowanych. Jak prawidłowo zrealizować logikę 'wszystko albo nic', gdy modyfikacja dotyczy kilku tabel?

Odpowiedź.

Pytanie z podstępem.