Antwoord.

In SQL is het vaak vereist om een 'alles of niets'-scenario te implementeren bij massale wijzigingen — ofwel slagen alle wijzigingen, of worden ze teruggedraaid bij een fout. Deze benadering wordt bereikt door gebruik te maken van transacties. De opgeslagen procedure moet expliciet een transactie starten (BEGIN TRANSACTION), de relevante bewerkingen omhullen, fouten afhandelen, en bij een fout ROLLBACK uitvoeren, anders COMMIT.

Vergeet niet om fouten correct af te handelen met constructies zoals TRY...CATCH (SQL Server) of EXCEPTION (PostgreSQL).

Voorbeeld voor 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;
        -- Foutlogging
        THROW;
    END CATCH
END

Misleidende vraag.

Vraag: Is het voldoende om alleen BEGIN TRANSACTION en COMMIT te gebruiken om een correcte terugdraaiing van wijzigingen bij fouten in alle ondersteunde DBMS te garanderen?

Antwoord: Nee, een transactie zelf vangt geen uitzonderingen. Het is noodzakelijk om handlers te gebruiken (TRY...CATCH of vergelijkbaar) om de fout te vangen en expliciet ROLLBACK aan te roepen. In sommige DBMS (bijvoorbeeld MySQL met autocommit) kan ook extra configuratie nodig zijn.

Voorbeeld van foutieve code (SQL Server):

BEGIN TRANSACTION;
UPDATE Users SET Name = 'Ivan' WHERE ID = 1;
UPDATE Orders SET Amount = Amount/0 WHERE UserID = 1; -- Deel fout door nul
COMMIT TRANSACTION;

In dit geval, als er een fout optreedt — blijft de transactie openstaan, en kunnen de wijzigingen in de eerste tabel behouden blijven.

Verhaal

Op een project van een webwinkel werd foutafhandeling in transacties vergeten, wat resulteerde in gedeeltelijk verlies van gerelateerde gegevens: als er een probleem optrad bij het bijwerken van de voorraad tijdens het bijwerken van een bestelling, werden alleen een deel van de wijzigingen teruggedraaid, waardoor de integriteit van de informatie werd aangetast.

Verhaal

In een BI-analyseproject werd een massale herberekening van rapporten doorgevoerd via een procedure zonder expliciete controle over transacties en foutafhandeling. Resultaat: een deel van de rapporten werd bijgewerkt, een ander deel niet. De uiteindelijke gegevens bleken inconsistent te zijn, aangezien noodsituaties niet leidden tot een atomische terugdraaiing.

Verhaal

In een bedrijf vertrouwden ze ten onrechte op autocommit in MySQL, zonder de transactiemodus in te stellen voor grote operaties. Bij een serveruitval was een deel van de gegevens al opgeslagen, een ander deel niet, wat leidde tot langdurige herstelwerkzaamheden en verlies van een deel van de bestellingen.

Leg de benaderingen uit voor foutafhandeling en terugdraaiing bij het werken met massale gegevenswijzigingen via opgeslagen procedures. Hoe implementeer je correct de 'alles of niets'-logica als de verwerking meerdere tabellen betreft?

Antwoord.

Misleidende vraag.