CodeGym /Kursy /SQL SELF /Zagłębiamy się w transakcje

Zagłębiamy się w transakcje

SQL SELF
Poziom 39 , Lekcja 0
Dostępny

Zagłębiamy się w transakcje

Już wcześniej w kursie wspominaliśmy, czym jest transakcja. Przypominam: to sekwencja operacji, która powinna być wykonana jako całość. No bo wyobraź sobie przelew bankowy. Wtedy zabieramy kasę z jednego konta i dodajemy ją na drugie. Jeśli jedna z tych akcji się nie uda (np. kasa została zabrana, ale nie dodana), robi się niezły bałagan. I właśnie tu transakcje ratują sytuację.

Transakcja albo wykona się w całości, albo wcale. To się nazywa zasada "wszystko albo nic".

BEGIN;
-- Zmniejszamy saldo na jednym koncie
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
-- Zwiększamy saldo na drugim koncie
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT; -- Zatwierdzamy zmiany

Jeśli coś pójdzie nie tak, możesz cofnąć zmiany za pomocą ROLLBACK.

Co to są właściwości ACID transakcji

Kiedy mówimy o transakcjach w PostgreSQL (i ogólnie w relacyjnych bazach danych), często pojawia się skrót ACID — i nie chodzi tu o chemię. ACID to Atomicity (atomowość), Consistency (spójność), Isolation (izolacja), Durability (trwałość). Te cztery cechy sprawiają, że dane są przetwarzane bezpiecznie, przewidywalnie i bez niespodzianek.

Atomowość (Atomicity)
Transakcja wykonuje się w całości albo wcale. Jeśli coś w środku pójdzie nie tak — wszystko się cofa. Wyobraź sobie: robisz przelew i nagle błąd — albo wszystko się anuluje, albo przelew idzie w całości. Żadnych "półśrodków".

Spójność (Consistency)
Po zakończeniu transakcji baza zostaje w poprawnym, logicznym stanie. Wszystkie reguły, ograniczenia i powiązania między tabelami muszą być zachowane. Na przykład, jeśli nie można mieć ujemnego salda, transakcja, która by to złamała, po prostu nie zostanie zapisana.

Izolacja (Isolation)
Dopóki jedna transakcja się nie skończy, inna nie powinna widzieć jej pośrednich danych. To ochrona przed dziwnymi efektami, kiedy widzisz "nieokreślony" stan danych. Wyobraź sobie, że w sklepie internetowym kasa już zeszła, a towar jeszcze nie został dodany do zamówienia — słabo, nie?

Trwałość (Durability)
Jeśli transakcja zakończyła się sukcesem, wszystkie jej zmiany są na bank zapisane. Nawet jak zaraz potem wyłączą prąd — dane zostają w bazie. To jak kliknięcie "Zapisz" i pewność, że wszystko jest na miejscu.

Te cztery cechy to podstawa tego, dlaczego transakcje są takim niezawodnym mechanizmem w pracy z bazami danych.

Przykłady scenariuszy użycia transakcji

Teoria jest spoko, ale prawdziwa moc transakcji wychodzi przy realnych zadaniach. Właśnie w takich sytuacjach — z kasą, powiązanymi tabelami czy masowymi zmianami — transakcje są niezastąpione. Pomagają nie tylko wykonywać operacje, ale robić to pewnie, bez ryzyka utraty danych czy zostawienia bazy w "półdziałającym" stanie.

Oto kilka typowych przykładów, gdzie transakcje naprawdę ratują skórę:

1. Obsługa płatności

Kiedy klient przelewa kasę z jednego konta na drugie, transakcja gwarantuje, że pieniądze nie znikną w próżni:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;
COMMIT;

Jeśli na pierwszym koncie nie ma wystarczająco środków, można cofnąć zmiany:

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE account_id = 1;
-- Ups, saldo ujemne!
ROLLBACK;

2. Aktualizacja powiązanych tabel

Wyobraź sobie, że zmieniasz status studenta na "absolwent" i jednocześnie dodajesz wpis do tabeli "absolwenci":

BEGIN;
UPDATE students SET status = 'graduated' WHERE student_id = 42;
INSERT INTO graduates (student_id, graduation_date) VALUES (42, '2023-06-10');
COMMIT;

Jeśli jedna z operacji się nie uda (np. błąd w INSERT), baza wróci do stanu początkowego.

3. Masowa aktualizacja danych

Transakcje są przydatne przy dużych aktualizacjach, na przykład:

BEGIN;
UPDATE orders SET status = 'completed' WHERE delivery_date < CURRENT_DATE;
COMMIT;

Jeśli serwer padnie albo zauważysz, że coś poszło nie tak, możesz cofnąć zmiany w każdej chwili!

Komendy do pracy z transakcjami

PostgreSQL daje kilka kluczowych komend:

  • BEGIN: rozpoczyna nową transakcję:

    BEGIN;
    
  • COMMIT: zatwierdza (zapisuje) wszystkie zmiany wykonane w ramach transakcji:

    COMMIT;
    

ROLLBACK: cofa wszystkie zmiany wykonane w bieżącej transakcji:

ROLLBACK;

Przykład pełnego cyklu

BEGIN;
-- Jakieś operacje
UPDATE accounts SET balance = balance - 200 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 200 WHERE account_id = 2;

-- Decydujemy się cofnąć zmiany
ROLLBACK;

-- Zaczynamy od nowa
BEGIN;
-- Te same operacje, ale inny przelew
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 100 WHERE account_id = 2;

-- Kończymy transakcję
COMMIT;

Życie transakcji poza podręcznikiem

Sklepy internetowe. Wiele platform używa transakcji do zarządzania zamówieniami i płatnościami. Na przykład zamówienie realizuje się tylko przy udanej płatności. Jeśli coś pójdzie nie tak, zamówienie automatycznie się anuluje.

Systemy bankowe. Transakcje chronią twoje pieniądze przed problemami typu nagłe wyłączenie prądu.

Historia transakcji. PostgreSQL trzyma logi WAL (Write-Ahead Logging) do odzyskiwania danych po awarii. To ta magia, która sprawia, że transakcje są niezawodne.

W następnym wykładzie rozłożymy komendy BEGIN, COMMIT i ROLLBACK na czynniki pierwsze, a także zobaczymy przykłady masowych operacji i częściowych cofnięć z SAVEPOINT. Do zobaczenia!

Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION