Relační databáze MySQL má za sebou již deset let vývoje a díky dobré podpoře v PHP je zřejmě nejrozšířenější databází používanou ve spojení s PHP. Od začátku byla MySQL vyvíjena jako rychlá a snadno použitelná SQL databáze. Proto vývojáři vypustili některé vlastnosti, které najdeme v konkurenčních produktech (např. transakční zpracování, kontrolu integrity pomocí cizích klíčů či vnořené dotazy).
Protože autoři naslouchali hlasu uživatelů, začali požadované vlastnosti postupně přidávat. Nejprve ve verzi 3.23 vznikla zvláštní odnož, nazvaná MySQL-Max, která zavedla nový druh tabulek – InnoDB. Od řady 4 jsou již InnoDB tabulky standardní součástí MySQL. Stabilní verze řady 4 vyšla v březnu 2003 (byla to verze 4.0.12) a letos v říjnu vyšla stabilní verze řady 4.1 (verze 4.1.7), která prošla několikaměsíčním testováním a momentálně je verzí doporučenou pro nasazení.
Abyste mohli využít většinu nových vlastností MySQL, které budu popisovat, potřebujete tabulky typu InnoDB. Standardně server používá typ MyISAM a vy máte dvě možnosti jak vytvářet tabulky jiného typu:
- Můžete upravit nastavení serveru. Aktuální nastavení zjistíte dotazem SHOW VARIABLES LIKE 'table_type';. Pokud je jiné, než potřebujete, připojte se k MySQL serveru jako superuživatel a použijte příkaz SET GLOBAL table_type = InnoDB;, nebo do konfiguračního souboru my.cnf přidejte řádek table_type=InnoDB (případně upravte již existující nastavení). Toto nastavení se projeví pro všechny nově vytvářené tabulky.
- Při vytváření tabulky určíte její typ. Například takto:
-
CREATE TABLE ukazka (cislo integer, jmeno char(20)) TYPE=InnoDB;
Pokud chcete změnit typ již existující tabulky, pomůže vám SQL dotaz ALTER TABLE tabulka TYPE=InnoDB. Dejte ovšem pozor při převádění velkých tabulek. Tabulky InnoDB totiž zabírají více místa než tabulky MyISAM, a proto by se mohlo stát, že se ještě před dokončením převodu vyčerpá místo pro databázi. Raději si připravte nějakou rezervu prostoru na disku.
Tabulky máme připraveny a můžeme se podívat, jaké novinky přinesla řada 4.0 a 4.1
Transakční zpracování
Určitě znáte situaci, kdy potřebujete provést několik SQL dotazů, které spolu souvisejí. Musí být zajištěno, že se provedou buď všechny, nebo žádný z nich. Například si představte účetní systém, který dělá v jedné transakci úpravu ve dvou tabulkách. Pokud by server zhavaroval uprostřed transakce, mohly by se do dat zanést chyby. A přesně tomu zabraňuje transakční zpracování. Předvedeme si to na příkladu:
START TRANSACTION; UPDATE ucty SET castka = castka - 300 WHERE cislo_uctu = 1432432532; UPDATE ucty SET castka = castka + 300 WHERE cislo_uctu = 2424214214; COMMIT;
Příkazem START TRANSACTION určíte, že chcete následující sérii dotazů zpracovávat transakčně. Transakci ukončíte příkazem COMMIT, a teprve poté se změny projeví v databázi. Pokud by selhalo provádění některého z dotazů, transakce se ukončí a databáze se uvede do stavu, v jakém byla před začátkem transakce. Pokud chcete, můžete transakci ukončit i manuálně příkazem ROLLBACK.
MySQL standardně funguje v "autocommit" režimu – to znamená, že automaticky provádí každý jednotlivý dotaz. Právě proto musíte začínat transakce příkazem START TRANSACTION. Pokud si chcete ušetřit psaní počátečního příkazu, můžete "autocommit" vypnout příkazem SET AUTOCOMMIT=0;. V tomto režimu se všechny dotazy zpracovávají jako transakce a musíte uvést příkaz COMMIT pokaždé, když chcete změny zapsat do databáze. Záleží jen na vás, který režim vám více vyhovuje.
Kontroly konzistence, cizí klíče
Jedním ze základních prvků relačních databází jsou vazby mezi tabulkami pomocí cizích klíčů (foreign keys). Například: vedete tabulku zákazníků a každému zákazníkovi přiřadíte jednoznačný primární klíč (například celé číslo). Do tabulky objednávek nezapisujete všechny údaje o zákazníkovi, ale do atributu zakaznik pouze zapíšete hodnotu odpovídajícího primárního klíče. Atribut zakaznik je tedy cizí klíč, protože odkazuje na primární klíč jiné tabulky.
Samozřejmě je potřeba kontrolovat, aby do cizího klíče nebylo možno zapsat hodnotu, která neodpovídá žádnému primárnímu klíči druhé tabulky (např. zapsat objednávku neexistujícího zákazníka). Také je nutno ošetřit stavy při změně či smazání primárního klíče, na který se odkazuje (např. změníme primární klíč nebo úplně smažeme zákazníka). Pomocí databázových omezení, do kterých spadá také problematika cizích klíčů, tyto činnosti zajišťuje přímo databázový server, ovšem v MySQL bylo nutno všechny kontroly provádět na úrovni aplikace. Díky InnoDB už tomu tak není.
Co je relační databáze?
Mnoho programátorů se domnívá, že relační databázi dělají právě vazby mezi tabulkami, často nazývané jako relace. To je ale mýtus. Může existovat databáze, která je relační i bez vestavěné podpory vazeb (tj. cizích klíčů) – takovým příkladem byla dlouhou dobu databáze MySQL.
Slovo "relační" má zde naprosto jiný význam. Když před desítkami let doktor E. F. Codd zavedl pojem relační databáze, pohlíželo se na tabulky jako na relace, se kterými se daly provádět různé operace. Z matematického hlediska to byl kartézský součin, selekce a projekce. Každá relační databáze vychází z těchto základů a musí mít v sobě zabudovánu podporu pro relační algebru, nad kterou se v jazyce SQL konstruují dotazy.
U nás vyšlo několik dobrých knih, které se více či méně věnují teoretickým základům relačních databází. Pokud jste žádnou z nich nečetli a problematika vás zajímá, doporučuji knihy Interbase/Firebird (P. Císař) nebo SQL – hotové příklady (L. Lacko).
Vnořené dotazy
Princip vnořených dotazů (sub-select, sub-query) je vcelku jednoduchý, o to víc času vám může ušetřit – v rámci jednoho dotazu použijete výsledek jiného. A jelikož příklad vydá za tisíc slov, opět si nějaký ukážeme. Dejme tomu, že chcete zjistit objednávky zákazníků, kteří mají dnes narozeniny.
SELECT * FROM objednavky WHERE id_zakaznik IN ( SELECT id_zakaznika FROM zakaznici WHERE narozeniny = CURDATE() );
Samozřejmě můžete použít v dotazu několik vnořených dotazů a také můžete ve vnořeném dotazu použít další vnořený dotaz. Tato vlastnost je přidána až v řadě 4.1, ale v manuálu najdete rady, jak podobného výsledku dosáhnout pomocí spojování tabulek (pomocí klauzule JOIN).
Vytváření tabulek podle vzoru
Od verze 4.1 si můžete usnadnit vytváření tabulek. Při použití příkazu CREATE TABLE nova_tabulka LIKE existujici_tabulka se vytvoří nová tabulka se stejnou strukturou, jakou má existující tabulka.
Cache dotazů
Kromě obecných pokroků ve zrychlení přibyla v řadě 4 také cache dotazů (query cache), která uchovává dotazy SELECT a k nim odpovídající výsledky. V případě, že se tabulka od posledního dotazu nezmění a aplikace znovu provede stejný dotaz, databázový server může výsledek vrátit mnohem rychleji. Pokud se obsah tabulky změní, cache pro daný dotaz se vyprázdní, aby server nevracel neaktuální výsledky.
Tato vlastnost může být velice užitečná u webových stránek, které nemění svůj obsah příliš často (např. jednou za den), ale často jej zobrazují. Autoři uvádějí nejlepší zjištěné zrychlení při použití cache dotazů až o 238 % a v nejhorším případě, kdy je cache zapnutá, ale obsah tabulek se neustále mění, zpomalení o 13 %. Dobře tedy rozvažte, zda je cache pro vaši aplikaci vhodná.
Embedded server
Vývojáři aplikací nyní mohou využít knihovnu libmysqld a vložit tak MySQL server přímo do své aplikace. Uživatelé se vůbec nemusejí zabývat instalací MySQL serveru a vývojář má jistotu, že jeho aplikace může fungovat naprosto nezávisle.
Další užitečné novinky
MySQL opět rozšířilo podporu SQL standardů a od řady 4 můžete používat sjednocení relací pomocí příkazu UNION.
Všechny, kdo pracují s daty v různých kódováních, určitě potěší podpora Unicode (konkrétně UTF-8 a UCS-2) zavedená v řadě 4.1. Dříve se podle nastavení znakové sady určovalo i pořadí záznamů při abecedním řazení. Při použití Unicode musíte určit, jak chcete řadit. Znakovou sadu a řazení můžete nastavovat na všech úrovních (od celého serveru až po jednotlivé sloupce tabulky) – při vytváření či změně databáze, tabulky nebo sloupce můžete SQL dotaz doplnit o COLLATE nazev. Stejně tak můžete doplnit i SELECT dotaz, pokud chcete "přebít" implicitní nastavení. Pro češtinu budou zřejmě nejpoužívanější latin2_czech_ci a cp1250_czech_ci.
Řada 4.1 také přinesla nový užitečný SQL příkaz HELP, kterým si můžete požádat o nápovědu k různým SQL příkazům. Máte tak vždy po ruce nápovědu a ta navíc přesně odpovídá verzi MySQL serveru, se kterým pracujete.
Co se chystá
V krátkosti se ještě podíváme, co slibují vývojáři MySQL pro řadu 5. Pokud se jejich plány splní, MySQL se určitě vyrovná velkým SQL serverům. Můžeme se tedy těšit na vlastnosti tradičních databázových systémů, jako jsou uložené procedury, views, kurzory, triggery a také plnou podporu cizích klíčů (momentálně fungují pouze pro tabulky InnoDB). Z dalších plánů jmenuji například další zrychlení serveru a přibližování SQL standardům. Pokud jim chcete nahlédnout pod pokličku, jsou k dispozici již první vývojové verze MySQL 5.0.
Licence
Nakonec zmíním licencování MySQL, které se změnilo již v roce 2000, ale někteří uživatelé stále nemají jasno. MySQL je poskytováno v rámci dvou licencí:
- GNU GPL, která umožňuje použití a úpravy MySQL serveru zdarma za podmínky, že i výsledný produkt je licencován pod GNU GPL. Tato přílišná přísnost vyvolala vlnu nevole u některých free a open-source projektů, takže projekty licencované v rámci jiných licencí získaly výjimku pro použití knihoven MySQL zdarma. Mezi licence, pro které platí výjimka, patří např. PHP License, Apache Software License či BSD license.
- Komerční – pokud z jakéhokoliv důvodu nemůžete nebo nechcete použít licenci GNU GPL, můžete si zaplatit komerční licenci a využít MySQL v libovolném (i komerčním a uzavřeném) projektu.