V Inno(xtra)db nemuzete nemit transakce. To byla s nejvetsi pravdepodobnosti proste necommitnuta transakce. Kazdy command i v shellu je v transakci. Akorat v shellu nemusite psat commit, pokud predtim rucne nenapisete begin. V ruznych knihovnach pro pristup existuji ruzne nastaveni autocommitu,pripadne "rucnich" commitu knihovny po kazdem commandu, ruzne isolation levely, atd a pak se zda, ze to funguje pokazde jinak. Neni pravda. Mysql svoje nedostatky ma, ale rozhodne ne ve vyse popsanych pripadech.
To je mi celkem jasné. Dost intenzivně používám PostgreSQL (už od dob Ingres/Postquel přes Postgres95) a tam mají tyto záležitosti poněkud delší tradici. Jen by mě nenapadlo hledat tyto problémy v aplikaci, kde byly použité dohromady čtyři primitivní SQL příkazy a žádné transakce. Dnes už je to nakonec jedno. Ta aplikace je dnes přepsaná o dvě úrovně výš.
Pokud to bylo skutečně způsobené transakcemi, je to pro mě opět důvod se MySQL raději vyhýbat. Důvodem pak není databáze samotná, ale lidé, kteří po MySQL sáhnou:
- LAMP - to M je tam MySQL, kdo kdy slyšel o LAP(ostres)P nebo LAS(qlite)P
- Volbou MySQL žádnou chybu nemůžu udělat
- Proč bych tam měl dát něco jiného, když MySQL je nejpoužívanější?
- Jak zprovozním phpmyadmin?
- Innodb? Ale to by bylo pomalé!
- Nesmyslné select... group by... v aplikacích
- U mě to funguje
- Jak to myslíš, transakce?
- Jak to myslíš, spojit joinem dvě tabulky?
- Jak zprovozním MySQL na Rpi? A proč mi to žere SD karty?
MySQL bývá pro tyto lidi první a jediná volba. Mám s podobnými aplikacemi několik hodně špatných zkušeností a pokusy o nápravu (jednání s autory) bývá natolik frustrující, že použití MySQL je pro mě jedním z prvních filtrů při výběru aplikace.
Neumím pracovat s MySQL a nechce se mi v neznámém prostředí zjišťovat, co nezkušený autor v aplikaci zeslonil. Je možné, že MySQL je dobrá databáze, ale společným jmenovatelem aplikací, se kterými jsem měl nejvíce problémů a vysvětlování zákazníkům, byla právě MySQL.