Názor k článku
Transakce a izolace transakcí v databázích

Co mě mrzí, je to kopnutí si do MySQL na začátku. Technický článek s politickým začátkem docela znechutí.

Jinak já vím, co jsou to transakce dobře, dělal jsem s velkými dbms ještě před tím, než jsem potkal MySQL, a sice jsem chvíli nadával, ale všude je něco, s čím se zápasí. V PostgreSQL se zápasilo s chybovostí až vysokých verzí, teprve až poslední roky se dá na PostgreSQL spolehnout, že nelikviduje data. A to nemluvím, jak dlouho PostgreSQL trvalo, než byla schopná poskytnout Windows port, což také leccos říkalo o schopnostech jejích vývojářů a o tom, jak byla programovaná. Takový Firebird vzniknul na unixech, pak ho adoptoval Borland a bez problémů jel na Windows, a pak se zase roztáhnul v platformách – je to naprosto jiná ukázka toho, jak se programuje multiplatformní kód. U Firebirdu se zase zápasí s nejhorší dokumentací co u projektu znám, a u dbms to bolí desetinásobně. To jen na vyváženost.

Jinak u MySQL bych opravil – triggery jsou tam napůl nepoužitelné. Triggery nesmí měnit tabulku, nad kterou sedí, což je z hodně použití (neříkám že ze všech) diskvalifikuje.

V zásadě bych řekl, že triggery v MySQL mají největší použití právě jako náhrada constraintů, protože umějí odmítnout sql příkaz. Možná tak byly i míněny.

Jinak s tím, že MySQL 5 vyšla předčasně bych se ztotožnil.

Ohledně Falconu, oni neměli jinou možnost, než potápět InnoDb a rozvíjet Falcon. InnoDb totiž nebyl jejich engine, a firmu InnoDb software koupil před časem Oracle, který jim mohl kdykoli zavařit a odepřít pokračování v poskytování InnoDb. Právě proto začali horečně rozvíjet nový, svůj vlastní engine Falcon a moc doufali, že jim Oracle nepřidusí vzduch, než ho dokončí. Ironií osudu je dnes MySQL v rukách Oracle, takže možná se změní celá strategie MySQL, kdo ví, každopádně se dá čekat leccos – od dobrých až po špatné zprávy.