|
|
| Тема |
 Re: прехвърляне на топката [re: Dakota] |
|
| Автор |
salle (един такъв) |
|
| Публикувано | 10.12.09 11:42 |
|
|
|
В отговор на:
Даваш ли си сметка, че ако SQL беше написан според твоите виждания операторът ROLLBACK нямаше да има право да съществува? А и COMMIT всъщност.
Това пък защо? Тъкмо напротив - единият (COMMIT) значи всичко, а другият (ROLLBACK) - нищо. И двата оператора имат своето място и значение за мен.
Въпросът ми е съвсем сериозен и те моля да отговориш защото това ще ти изясни къде е проблемът в твоята логика.
Ако транзакциите работят така както ти очакваш кога и при какви обстоятелства изобщо би ти се наложило да използваш ROLLBACK?
Следвайки твоята логика отговорът трябва да е: Никога! А оттам следва, че и от COMMIT всъщност няма нужда.
Транзакцията (логическата операция) "банков превод" се състои от две операции върху БД - намаляване на едната сметка и увеличаване на другата:
BEGIN;
UPDATE account SET money = money - 200 WHERE id=1;
UPDATE account SET money = money + 200 WHERE id=2;
COMMIT;
Ако видиш някой твой подчинен да пише такива транзакции моментално то уволнявай
След всеки UPDATE клиентската част трябва да проверява за проблеми и да продължава със следващия оператор само ако няма такива в противен случай да праща ROLLBACK
Забележи, че казвам проблеми а не грешки! Напълно е възможно даден оператор да мине чисто, но въпреки това да има селиозен проблем.
Представи си, че в твоя пример резултатите са без грешка но:
UPDATE account SET money = money - 200 WHERE id=1;
Query OK, 1 row affected (0.00 sec)
UPDATE account SET money = money + 200 WHERE id=2;
Query OK, 0 row affected (0.00 sec)
Ако действаме по твоята логика, че отговорността е изцяло на сървъра и му се доверим, че ще открие всички проблеми какво се получава в този случай? Атомарна транзакция, която оставя боза след себе си.
Това което ти убягва в цялата работа е, че обработката на транзакции се случва в среда Клиент-Сървър а не само и единствено в Сървъра.
| |
| |
| 
|
|
