PostgreSQL: Common Table Expressions

Při trochu pokročilejších databázových dotazech jsou často využívané korelované dotazy, kde výstup jednoho dotazu poskytuje datovou množinu pro další dotaz. Nejsou velmi efektivní, při požadavku na jejich rychlost je nezřídka nutné mít vytvořený i jinak zcela nelogický index a často je lze nahradit mnohem „čistším“ JOINem. Další možnost nabízí Common Table Expressions (dále jen CTE), které jsou zatím opomíjené.

Pokračování textu PostgreSQL: Common Table Expressions

Flattr this!

SQL: podmínka v UPDATE

Každý, kdo pracuje při programování s databázemi, zná příkaz UPDATE a ví, jak se aktualizuje konkrétní řádek/řádky, když si je omezí podmínkami v části WHERE. I měněnou hodnotu lze zapodmínkovat, aby se ušetřil zbytečný dotaz.

Pokračování textu SQL: podmínka v UPDATE

Flattr this!

MariaDB, kde to vázne vážení webhosteři?

MariaDB je na světě téměř 5 let (22. ledna 2009 byla vydána první verze) a ačkoliv si nachází cestu do distribucí GNU/Linuxu, aškoliv ji testují a nasazují provozovatelé nejvíce navštěvovaných webů, tak webhostingy, minimálně v ČR/SR ji zatím přehlíží. Zcela neoprávněně, stejně jako defakto ignorují PostgreSQL o němž lze napsat, že je to „funkčně open source konkurent Oracle“.

Pokračování textu MariaDB, kde to vázne vážení webhosteři?

Flattr this!

SQL: Indexujte a experimentujte s indexy

Dovolím si navázat na článek „Jak psát kód: Databázové indexy vytvářejte při psaní dotazů“ Jakuba Vrány. Na indexaci je dobré klást důraz při návrhu databáze, odobně ji řadím na 2. místo za správným ER modelem, a drtivá většina databází nabízí nástroj pro vyladění indexů. Vedle indexů stojí složité dotazy, jejichž využitím lze z SQL databáze dostat data efektivněji a jichž se není nutné bát.

Pokračování textu SQL: Indexujte a experimentujte s indexy

Flattr this!

Databáze pro eshop/cms, váhání mezi MySQL/MariaDB a SQLite

Evidentně nejsem první, kdo dospěl do stavu, kdy řešení webů v instantním open source systému začíná být nepohodlné. Nekritizuji funkčnost; byť ZenCart mi připadá jako učebnice toho, jak se psát nemá a hlavně jak nemá aplikace používat databázi; ale při potřebě dopsat vlastní rozšíření/úpravy to prostě bolí. Pronikání co cizího způsobu psaní kódu a prohledávání neznámého frameworku asi nemá rád žádný programátor.

Pokračování textu Databáze pro eshop/cms, váhání mezi MySQL/MariaDB a SQLite

Flattr this!

MySQL: Vícesloupcový podvýběr

Výběry z tabulek jsou často využívány v nejjednodušší možné podobě SELECT * FROM `tabulka` WHERE podmina, zkušenější programátoři hnězdičku moc nepoužívají, vyjmenují pouze sloupce které potřebují, čímž trochu sníží datová zátěž pro přenosy mezi serverem a aplikací. Hodně používaný je JOIN (celá řada „programátorů“ skončí u LEFT JOIN) a v oprávněných případech někdo používá podvýběry.

Pokračování textu MySQL: Vícesloupcový podvýběr

Flattr this!

MySQL: Vliv pohledů na výkon?

Není to tak dávno, co jsem psal o opomíjených pohledech v MySQL a tvrdil jsem, že mohou ušetřit čas. Jak se zdá, tak ušetří čas leda programátorovi, pokud je použije vhodným způsobem. Reálně mohou pohledy způsobit pokles výkonnosti. Otázka tedy pak tedy zní, kudy z problému ven, jestli přechodnou tabulkou, které se vytvoří pro otevřenou session, nebo ručním napsáním všech podmínek, jimiž jsme vytvořili pohled, a (?menší?) nepohodlí pro programátora.

Pokračování textu MySQL: Vliv pohledů na výkon?

Flattr this!