Prečo konfiguráciou vynucovať InnoDB? Osobne používam InnoDB, ak potrebujem transakcie a ostatné mám na MyISAM. Výhoda je tá, že ak vložím počas transakcie záznam do MyISAM tabuľky, tak sa uloží bez ohľadu na výsledok transakcie. To je vhodné pri logovaní zložitejších transakcií. Možno sú aj lepšie spôsoby logovania, ale toto je povedzme, že najjednoduchší.

Samozrejme som si vedomý, že MyISAM podporuje transakcie od verzie MySQL 5.6, takže tam by sa to muselo riešiť inak, ale kým sa 5.6 bude používať, tak to ešte chvíľu potrvá.

Vynucení InnoDb jsem dal jako jednu z možností. Protože optimální práce MyISAM vyžaduje mít nastavenu řadu bufferů na správné velikosti a to zbytečně bere paměť i prostředky. Kromě toho MyISAM hůře zamyká a případné problémy se řeší hůře. Není vůbec problém zablokovat server a přetížit ho SQL dotazem na MyISAM tabulku.

Jednoduše, na MyISAM se kašle při vývoji. To tam zůstává spíše jako startovací engine, ze kterého si MySQL přečte práva. Ale vývoj jede na InnoDb.

Spoléhat na to, že nějaké tabulky jsou mimo transakce – to není čisté řešení a může se časem vymstít. Jako čistější a v zásadě jednodušší a přitom zaručené a čisté řešení mi přijde otevřít si dvě konekce k databázi. Na jedné provádět transakce a ve druhé konekci logovat s autocommitem, nebo ručním commitem. Máte tu samou funkčnost, ale čistě a bez problémů a závislosti na vnitřní implementaci a vlastnostech MyISAM engine, kde byste musel paranoicky číhat, jestli není změněna vnitřní implementace MySQL.

Miloslav Ponkrác

MyISAM je už označený za deprecated, od MySQL 5.6 je InnoDB defaultní engine. Mimochodem jediné co zatím InnoDB úplně nemá je fulltextové vyhledávání, ale i to se do finálního vydání změní (viz. článek na The H). Pokud používáte jen základní SQL je Vám jedno který typ tabulek, ale Stored Procedury a transakce pojedou nejlépe v InnoDB.

S tím jak Oracle nenápadně ořezává OSS podporu bude dobré sledovat, jak si poradí vývojáři MariaDB, případně pořešit se svým webhosterem přechod na PgSQL (jakkoliv MySQL ji funkčně dorůstá).

Pokud někdy Oracle zruší závislost tabulek práv na MyISAM, pak není proč by tam MyISAM vůbec zůstalo.

InnoDB už fulltext umí v MySQL 5.6, mají to i v manuálu. (http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html) Kromě toho MySQL 5.6 udělala revoluci v datovém typu timestamp.

Oracle už útočí. Prostě postupně odstřihne MariaDB od informací. Ze zdrojových kódů postupně odstraní testové, benchmarkové a pomocné části, které nejsou potřeba ke zkompilování, ale ztíží testy kompatibility, nebo i samotné sestavení. Mohou také stopnout dokumentaci, která není pod GPL licencí.

Mimochodem, tento stav je způsoben právě autorem MariaDB, který odstraněním dokumentace z GPL licence chtěl mít kontrolu nad MySQL. Po prodeji MySQL, ze kterého měl autor MariaDB nemalé peníze teď začíná protestovat proti tomu co se s MySQL děje – ačkoli těžko říci, jak moc férové to je.

Featury bude Oracle přednostně uvádět do placeného produktu, zatímco do Community Edition, která je open source bude stagnovat.

Může také stopnout FOSS dodatek a tvrdě nařídit GPL pro všechny klienty.

Open source klienty stopne tak jako PHP. PHP napsalo mysqlnd klienta, který se ovšem není schopen připojit k mysql serveru, pokud jsou hesla vytvořená pomocí OLD_PASSWORD funkce. MySQL 5.6 má znovu změněnou funkci pro ukládání hesel – samozřejmě za silnější, ale hlavně nekompatibilní s PHP.

Pokud se nezmění strategie, tak Oracle dříve nebo později MySQL jako open verzi stopne. Možná ne přímo, ale nepřímo to znemožní nebo ztíží natolik, že to oficiálně bude open source, neoficiálně to bude jinak.

Je třeba se připravit, že s velkou pravděpodobností bude muset být udělán fork nebo hledat náhradu.

Nejsem si ovšem jist, zda je PostgreSQL ideální náhrada. Cílové použití u MySQL a PostgreSQL není úplně shodné. MySQL má embedded verzi a slouží (i jako neembedded verze) jako malá databáze do řady aplikací. MySQL je perfetkně portabilní na různé platformy, PostgreSQL stále nemá plnou funkčnost na neunixových platformách, protože s nimi nepočítalo, ba je někdy i nepokrytě nenávidělo. I když se situace hodně zlepšila.

Perfektní náhrada mohl být Firebird/Interbase, ale tam to zabili naprosto katastrofálním stavem dokumentace.

Chlape umíte psát stručně? :-D

MySQL 5.6 už je GA? Nebo je ještě stále Milestone/RC? Proto odmítám tvrzení „umí“, protože nějak nejsem vzít vlastnosti jako definitivní. Teprve po GA má význam řešit podporu connectorů, či považovat schopnosti za definitivní.

Podpora MyISAM jentak nezmizí, kvůli kompatibilitě se staršími databázemi. Byl bych zatraceně opatrný v tvrzení že to mohou udělat automaticky po otevření databáze v novém serveru, to nemusí projít.

FirebirdSQL (a už jsme jinde oba komentovali stav dokumentace) je skvělý server, ale s Vámi přesně popsanou slabinou. Jako bonus nefunguje embedded verze na síťovém disku. Trochu opruz je tvorba domén, na pozadí, i při používání základních datových typů. Já spíš jako embedku používám SQLite, či Apache Derby :-), ale ty funkčně nesahají FbSQL ani po kotníky.

Odpověď na první odstavec: Ano. :-)

Oracle vyvíjí vcelku seriózně a nedělá excesy. Pokud je něco release candidate, tak se vcelku dá spolehnout. Navíc ta verze 5.6.7 existuje, lze jí stáhnout, vyzkoušet, …

Vím, že podpora MyISAM nezmizí. Ani ne tak kvůli kompatibilitě se staršími databázemi, protože binární kompatibilita datových souborů není nutná feature. Spíše by byla velká práce odstranit MyISAM úplně, ale očekávám, že Oracle postupně míří směrem odstranit pojem „storage“ z MySQL zcela.

Jestli je Firebird skvělý server téměř nikdo netuší. Není-li dokumentace ani na úrovni, že si bez investice do komerčních knih nejste s to ani zjistit základní ucelenou informaci o datových typech, sql jazyce a základních tématech Firebirdu (a knihy jsou vždy pozadu za skutečností) – pak osobně se zříkám jakéhokoli hodnocení Firebirdu. Podle mého nelze databázi s takovým stavem dokumentace za skvělou vůbec prohlásit. Sám si vzpomínám na dobu, kdy jsem chtěl začít Firebird používat, ale s hrůzou jsem zjistil, že je třeba se ptát vývojářů i na to, jak se tam vlastně chová null a jaké jsou tam datové typy.

Sqlite jsem kdysi otestoval a už se ho neodvážím použít. Autor několikrát do roka významně přepíše jádro sqlite. Takže některé verze jsou super a jiné třeba ztrácí data. Takže při testu, zda použiji sqlite do jednoho projektu jsem stáhnul poslední stabilní verzi a hned na začátku testu jsem zjistil, že občas mizejí data uložená do sqlite tabulek. Když jsem se obrátil na fórum, dostal jsem vynadáno jak malý kluk, že mám přeci vědět, že některé verze – ač označené za stabilní – jsou prostě špatné a mám se na fóru ptát, kterou použít. Takže sqlite jsem se neodvážil použít.

Zkrátka MySQL má jednu věc – je spolehlivá, skutečně multiplatformní, dobře zdokumentovaná, dobře pracuje s thready, a na dbms malého typu je překvapivě vyspělá. A skutečná náhrada za ní v její nice a v její dotaženosti není.