Vlákno názorů k článku Buďte moderní (v SQL) od Pavel Stěhule - 1) čemu vadí transakce - to je pomůcka...

1) čemu vadí transakce - to je pomůcka pro programátora, aby nemusel řešit zámky a aby nemusel po sobě uklízet. U složitějších aplikací si nedovedu představit nepoužití transakcí.

2) RI a další integrity jsou primárně pro programátory. Včas praští přes prsty, když někdo něco dělá jinak než bylo očekáváno. Default není CASCADE delete, ale vyhození chyby. Pokud zjistím, že nemohu nějakou operaci udělat kvůli nastaveným podmínkám, a po zralé úvaze zjistím, že ta podmínka je zbytečná, neaktuální, tak tu podmínku vyhodím. Co je důležité - po zralé úvaze. Ne, že někdo přijede do podniku, něco promaže, a pak se zjistí, že to je průser. RI integrita je nástroj, jak nemít v databázi bordel. Je jasné, že pravidla někdy omezují - když jsem nastavil constrainty v jedné aplikaci, tak obchoďáci týden frfňali, protože museli vyplňovat formuláře správně - ale další lidi už s tím neměli práci při párování, a v databázi byla data, na které se bylo spolehnout a ne snůška poznámek.

3) určitě je možné aplikaci napsat tak, aby fungovala se všemi databázemi. Viz různé wikiny, blogy, atd. Tam, kde je databáze složitější a jsou složitější databázové operace je to pro O.S. blbost a ztráta času. Mariadb, Firebird, Postgres jsou optimalizované pro jiné use caces, a nabízejí jiné možnosti, jiné datové typy. U komerčních databází je jasné, že když někdo už zaplatil za Oracle a má na to lidi, tak bude preferovat Oracle (nebo MSSQL, ...). U O.S. databází to neplatí - navíc vzhledem minimálním nárokům na údržbu většinou o O.S. databází uživatel ani neví - takže je mu jedno, co provozuje. Navíc dneska s virtualizací už pro menší aplikace nepotřebujete ani dedikované železo.

4) prepared statements mohou pro jednoduché a frekventované dotazy znamenat výrazné zrychlení - záleží na databázi a prostředí - minimálně 20-50%. Bacha, vždy jsou výjimky - někdy jsou pro konkrétní parametry hůře optimalizované. Ještě další zátěž jsou síťové operace, síťové latence - proto uložené procedury - jenom přepsáním kódu do uložené procedury jsem zrychlil operaci z půl hodiny na 5minut - a to to běželo lokálně. Ve storkách příkazy neběží rychleji, ale pokud se sdruží, tak odpadnou síťové latence, což u dotazů kolem pár ms může znamenat výrazné zlepšení.

5-6) U CTE jsou techniky, jak identifikovat cykly - případně jak rekurzi omezit. A pokud by CTE poté nebylo čitelné nebo rychlé, tak minimálně v Postgresu není problém napsat funkci vracející tabulku volanou rekurzivně, kde má člověk všechno pod kontrolou. Případně je možné už při zápisu hledat cykly - a ty prostě nedovolit.

Pouze potvrzujete to, že nevíte, k čemu transakce slouží.

To, že se ve vašem případě nejedná o účetnictví, vůbec nevadí. Transakce neslouží jenom pro účetnictví – transakce slouží (spolu s mnoha dalšími nástroji) k tomu, aby model, který vytváříte v počítači, odpovídal realitě. V software třeba klidně naplánujete na jeden stroj na jednu hodinu dvě různé výroby. V realitě vám to samozřejmě neprojde, ten stroj se neumí naklonovat – a transakce jsou jedním z nástrojů, který pomáhá tohle ošetřit i v tom softwaru. Nástroje pro to existují různé, lze se obejít i bez transakcí – ale pořád musíte vědět, jaký problém vlastně řešíte.

Váš problém „kam napsat begin a commit“ je problém umělý, protože řešíte „nějaké transakce“ a ne to, k čemu ty transakce mají sloužit. Ve skutečnosti je to tak, že máte nějaké požadavky, které potřebujete splnit, a transakce je jenom nástroj, kterým to uděláte. Neřešíte, kde má být BEGIN a kde COMMIT – to plyne z reality. Naopak, to co se vám ocitne mezi BEGIN a COMMIT nazvete jednou transakcí.

„Transakce nejsou zadarmo“ je úplně převrácený pohled. Vy nepotřebujete v systému nějaké transakce, které tam musíte draze přidávat. Vy v systému potřebujete zajistit splnění určitých předpokladů – a transakce jsou způsob, jak to snadno a levně zajistit.

Pomohlo by vám, kdybyste na chvíli přestal používat pojem transakce a místo toho psal o tom, čeho chcete transakcemi dosáhnout. Ten váš příklad je, jako kdybyste u dvoupatrového domku řešil, kam umístíte schody. Máte dvě hlavní strategie – 1. umístit je na zahradu co nejdál od baráku, aby se daly využívat maximálně samostatně a v domě nepřekážely; 2. položit je do obýváku, protože tam budou lidé nejčastěji a ty schody se tak maximálně využijí. Jenže když přestanete řešit, kam umístit schody, a uvědomíte si, že je nějaký důvod, proč ty schody v baráku chcete mít, vzpomenete si, že vlastně potřebujete nějak propojit přízemí s prvním patrem, a k tomu právě mají sloužit ty schody – takže je logicky musíte umístit tak, že vedou z přízemí do prvního patra. Přičemž samozřejmě místo schodů můžete mít i výtah. Pokud vám ten příklad připadá absurdní – kdo by dával schody na zahradu nebo naležato, když potřebuje propojit přízemí s patrem – vězte, že stejně absurdní připadají mně vaše popisy transakcí. Přestaňte řešit, kam umístíte schody, a vraťte se k tomu, že potřebujete propojit přízemí s patrem – a přestaňte řešit transakce, a vraťte se k tomu, co jste transakcemi chtěl řešit.

Cilem je zajisteni konzistence dat.
Cílem transakcí je atomičnost změn, konzistence dat, izolovanost změn a trvanlivost změn (ACID). Pokud by vám stačila konzistence dat, nepotřebujete plnohodnotné ACID transakce.