|
Така, уверих се, че и в Oracle поведението е същото като в MySQL, т.е. несправедливо обвиних последната първоначално. Но за останалото не съм съгласен.
В отговор на:
Даваш ли си сметка, че ако SQL беше написан според твоите виждания операторът ROLLBACK нямаше да има право да съществува? А и COMMIT всъщност.
Това пък защо? Тъкмо напротив - единият (COMMIT) значи всичко, а другият (ROLLBACK) - нищо. И двата оператора имат своето място и значение за мен.
В отговор на:
Аз пък (и повечето DBA които познавам) категорично не желая СУБД да си решава какво да прави.
Именно. Нали точно за това става дума, че не желая БД зад гърба ми да прави rollback до savepoint, освен ако изрично не съм й казал да го прави. А аз не съм.
В отговор на:
Ти разглеждаш многоредовата транзакция като нещо монолитно...
А какво значи атомарността, според теб? Може ли атомът да се раздели на нещо по-малко без да бъде унищожен?
Та нали точно това е смисълът изобщо на понятието транзакция - че представлява една неделима логическа операция, която е възможно на ниско ниво да е изградена от множество физически операции върху различни обекти в БД. И тук е напълно уместен класическият пример с банковия превод.
Транзакцията (логическата операция) "банков превод" се състои от две операции върху БД - намаляване на едната сметка и увеличаване на другата:
BEGIN;
UPDATE account SET money = money - 200 WHERE id=1;
UPDATE account SET money = money + 200 WHERE id=2;
COMMIT;
Какво се случва, когато първата операция не мине по някаква причина, а втората - да? Появяват се 200 лв. от нищото.
С други думи - получава се транзакция, която не е атомарна, т.е. противоречаща на един от четирите основни принципа, на които трябва да отговаря всяка транзакция.
В отговор на:
Ако си стигнал до момента в който изпращаш COMMIT това означава, че транзакцията все още е активна т.е. сървърът не е намерил причина за неявен ROLLBACK...
А защо не е намерил причина? Какво трябва да се случи, за да намери причина? Не е ли нарушаването на ограниченията, заложени върху обектите в БД достатъчна причина за това?
По тази логика за какво са ни транзакции изобщо? Дай да решаваме на парче в приложението всичко.
Не съм съгласен. Когато използвам транзакция има основателна причина за това и тя е, че искам БД да гарантира определени неща (самата тя - базата, като подлог). Така го пише и в (което предполагам е взето от книгата на Андреас Ройтер и Тео Хардър):
"Atomicity refers to the ability of the DBMS to guarantee that either all of the tasks of a transaction are performed or none of them are...
... Atomicity states that database modifications must follow an “all or nothing” rule. Each transaction is said to be “atomic” if when one part of the transaction fails, the entire transaction fails."
А това, че самата транзакция е интерактивен процес, също е от значение, но твърдо не трябва тази интерактивност да става оправдание за нарушената атомарност. Твърдо не и по подразбиране.
Ето, например, често ми се случва да пиша SQL скриптове със стотици редове чист SQL код и да го пускам на конзолата наведнъж. И те всички са една логическа операция или т.нар. транзакция. И твърдо имам нужда от атомарност, просто защото ако някоя от инструкциите се провали, следващите след нея няма да имат никакъв смисъл. Или още по-лошо - ще имат смисъл, но той ще бъде напълно погрешен. И това не важи само за тези транзакции, в които има DDL инструкции (които прочие не се поддържат транзакционно нито от Oracle, нито от MySQL), а изобщо.
Ако пък по изключение има някаква част от транзакцията, която има незадължителен характер, то аз имплицитно ще я обособя със SAVEPOINT. Но това ще е изключение, което аз умишлено съм разрешил, а няма да е поведението по подразбиране. Просто защото нещата могат да се объркат на места, на които най-малко си очаквал. И практиката го потвърждава постоянно.
"Договор, подписан с Русия, струва по-малко от хартията, върху която е написан!" - БисмаркРедактирано от Dakota на 09.12.09 18:15.
|
прехвърляне на топката [re: salle]
