Články v rubrice Databáze

Začátkem prosince byla založena organizace MariaDB Foundation, která nyní zastřešuje vývoj databáze MariaDB. Snahou projektu MariaDB je vrátit MySQL zašlou otevřenost, o kterou pomalu přichází pod vedením firmy Oracle. Ta koupila databázi MySQL společně s firmou Sun a od té doby postupně uzavírá její vývoj.

V relačních databázích se běžně setkáváme s dvěma typy databázových relací (lišících se svou strukturou a chováním). Nejčastějším typem je halda (heap) a index. V haldě jsou záznamy v nedefinovaném pořadí. V indexu (Btree) pak jsou záznamy uspořádané podle vybraného klíče.

Je fascinující sledovat stopy INGRESu (projektu, který byl zahájen více než před třiceti roky) v moderním a rozšířeném PostgreSQL. Příkaz COPY, příkaz createdb, backslashové příkazy v SQL terminálu, návrh některých systémových tabulek – to je vše živým odkazem tohoto úžasného projektu.

Vývoj 9.2 pokračoval v kolejích vyjetých 9.0 a 9.1. Díky tomu, že v loni a předloni se vyřešily některé diskutabilní otázky, poslední rok byl hlavně a jen o práci. Ne, že by se občas nevedly bouřlivé diskuze. Ale téměř vždy se poměrně rychle podařilo najít kompromis, který byl často kvalitnější než původní návrhy.

Pokud jste si někdy přáli mít stejná data ze své MySQL databáze na více místech najednou, tak tento článek vás jistě potěší. Dnes si totiž ukážeme Master – Slave replikaci na MySQL, což je databázová funkce, která přesně toto dělá. Řekneme si také proč je dobré replikovat a také si ukážeme, jak na to.

V následujícím článku bych chtěl zkompletovat sérii článků, které jsem o PL/pgSQL pro Roota napsal. Kvůli PL/pgSQL jsem si vybral PostgreSQL a vlastně kvůli PL/pgSQL jsem se stal jedním z vývojářů PostgreSQL – při práci na jednom projektu mne PL/pgSQL drobet štval, tak jsem napsal patch, který byl přijat.

Bandicoot je nový programovací systém založený na relačnom modeli. Cieľom tohto článku je implementácia ukážkovej webovej aplikácie s použitím Bandicootu a JavaScriptu. Nasledujúce odstavce popisujú, ako vytvoriť jednoduchú aplikáciu. Na perzistenciu a kalkulácie s dátami je použitý Bandicoot.

Relačný model je dobre známym pojmom v oblasti softvérového inžinierstva. Tento dvojdielny článok vám predstaví projekt Bandicoot, ktorý implementuje relačný model netradičným spôsobom. Zároveň si ukážeme, ako vyvíjať softvér pomocou relačného modelu, a to bez použitia tradičných relačných databáz či jazyka SQL.

Po roce je tu nová verze PostgreSQL – respektive máme tu betu – a je tudíž jasné, co v 9.1 bude a nebude. V podstatě až na příkaz MERGE, který bude až v 9.2, byly plány pro tuto verzi splněny. PostgreSQL nyní podporuje COLLATION podle ANSI/SQL. Nechybí ani podpora SQL/MED (čtení externích csv souborů).

Z mého pohledu byl rok spojený s pracemi na 9.0 asi nejklidnějším rokem, který pamatuji (z pohledu vývojáře): Organizace vývoje založená na commitfestech se osvědčuje. Vývojáři, kteří pracují na náročných, problematických funkcích, se už smířili s tím, že se nic nedá uspěchat a že život není jen programování.

Velmi rozšířený a oblíbený databázový server MySQL udělal za posledních několik let významný pokrok a k jednoduchému rychlému úložišti přidal i některé pokročilejší funkce. Na část vlastností je ale potřeba si dát pozor, některé z nich přímo nefungují. V následujícím článku uvádím ty nejviditelnější z nich.

Pole a relační databáze nejdou dost dobře dohromady - alespoň na první pohled. Rozhodně podpora polí v relačních databázích není úplně běžná, a osobně si myslím, že je to možná i dobře. V databázovém systému, který pole podporuje, lze k databázi přistupovat skutečně jako k pouhému úložišti dat.

Bezpečnost dat dnes znamená všechno zdvojovat. Máme dva disky, máme druhý stroj na zálohy, máme dvě linky do Internetu a nebo také dvě auta, abychom si byli jistí, že se k serverům dostaneme. Když se nám povede umístit data online na dvě místa, můžeme mluvit o úspěchu. Dnes si povíme, jak to udělat s Postgresql.

Kdyby neexistovala MySQL, tak by transakce patrně nebyly tak populárním tématem. I když ne všechny databáze byly a jsou transakční, nikdo (do nástupu MySQL) netvrdil, že transakce jsou něco „navíc“. MySQL přišlo s novou filozofií - databáze nemusí být až tak 100% spolehlivé, hlavně musí být rychlé.

V článku bych rád ukázal cestu ke dvou novým funkcím PostgreSQL - CTE a analytickým funkcím. Z pohledu SQL o nic nového nejde - tyto funkce jsou dobře známé z komerčních databází. Z pohledu OSS databází se jedná o významný krok k plné implementaci ANSI SQL 200x a ke znatelnému rozšíření komfortu vývojářů.

Na svých kurzech, trochu s nadsázkou, tvrdím, že programátor, který použije LIKE, si koleduje o to nebýt programátorem. Nedávno se na dbsvětu objevil na toto téma článek. To je jistě přínosné, bohužel zmiňovaný článek nešel příliš do hloubky. Co je na tomto na první pohled neškodném operátoru tak hrozného?

Každoročně přinášíme článek věnovaný novinkám v PostgreSQL a ani letošní rok nebude výjimkou. V březnu finišují práce na dokončení verze 8.4, která by měla být k dispozici začátkem léta. Na nové funkce se uživatelé dlouho těšili - podpora rekurzivních a analytických dotazů. Co nás přesně čeká?

Určení vlastníků db objektů se v řadě projektů vůbec neřeší nebo řeší příliš pozdě. To už obvykle chaos ve vlastnictví začne komplikovat administraci. Tento článek se věnuje popisu problematice vlastnictví db objektů a jako bonus obsahuje pár užitečných základních doporučení.

Každý, kdo trochu déle pracuje s SQL databázemi, časem narazí na "prováděcí plány dotazů". Zatímco SQL dotazy je možné navrhovat bez hlubší znalosti konkrétní databázového systému, při optimalizaci dotazů se pak bez těchto znalostí neobejdeme. Prvním krokem při optimalizaci je právě analýza prováděcích plánů.

Korelované poddotazy zásadně rozšiřují funkcionalitu SQL. Je ale třeba zároveň říci, že zpracování SQL dotazu obsahující korelovaný poddotaz je poměrně náročné. Navíc prakticky ve všech případech existují efektivnější způsoby, jak danou úlohu vyřešit lépe a bez korelovaného poddotazu.

Outer join (left nebo right) je pravděpodobně nejkomplikovanější část příkazu SELECT - alespoň pro začátečníky. Jakmile tuto klauzuli zvládnou, tak zvládli SQL. Jsou tu ještě pasti v podobě korelovaných poddotazů. Těm se ale lze vyhnout, zato spojování tabulek je denním chlebem skoro každého kodéra.

Překvapivé otevření kódu 602SQL Serveru je patrně jednou ze zásadních událostí na domácí IT scéně. 602SQL Server je ukázkou, jak relativně kvalitní produkt díky špatnému marketingu a podpoře nedokáže držet krok s konkurenčními produkty a ani s open-source konkurencí. Otevření kódu bohužel přichází pozdě.

Během dnešního dne bude uvolněna beta PostgreSQL 8.3. To znamená, že se do kódu dostanou již pouze opravy a je proto docela jisté, jak bude nová verze PostgreSQL vypadat. Od vydání bety do vydání ostré verze se v případě PostgreSQL čas měří na týdny, takže se můžeme začít těšit na ostrou verzi.

Uživatelé, kteří přechází z MySQL nebo Firebirdu, občas naráží na "inteligenci" PostgreSQL. V PostgreSQL není žádný způsob, jak jej donutit použít konkrétní index, a ještě se to považuje za výhodu. I když má PostgreSQL zřejmě nejpropracovanější optimalizaci ze všech open-source databází, mohou nastat situace, kdy optimalizace selže a sql dotazy trvají příliš dlouho. Kdy se tak stane a jak to řešit?

Rok intenzívního vývoje PostgreSQL vývojáři uzavřeli uvolněním beta verze 8.2. Na plnou verzi si ještě budeme muset počkat do Vánoc, nicméně už nyní si můžeme vytvořit představu o další verzi. Asi nejočekávanější podpora bitmapových indexů a editovatelných pohledů chybí. Neznamená to ovšem, že by se přechod na tuto verzi nevyplatil.

Když jsem se poprvé setkal s rekurzí, vůbec jsem nechápal, o co jde. Většina překladačů a interpretů ji nepodporovala a spíš se hledaly nerekurzivní řešení. Staré časy - MicroBáze Pascalu, TurboPascalu. Jsem rád, že mám na co vzpomínat. Dost nostalgie. Rekurze tu je.

Podpora uložených procedur v MySQL5 znamená, že všude, kde bude nainstalována tato databáze, máme k dispozici určité minimální prostředí pro běh našich SQL/PSM skriptů. Tedy řadu úloh můžeme vyřešit přímo v MySQL bez potřeby instalace dalšího dodatečného software - generování testovacích dat, filtrování, transformace a podobně.

Zkuste si napsat vlastní debugger uložených procedur. Brzo zjistíte, že to není žádná legrace. Proč? Jednak debugger je typicky interaktivní aplikace, a prostředí uložených procedur se ani náhodou nedá označit jako interaktivní. Navíc se snažíte ladit kód, který je prováděn vzdáleně. Řeknu to rovnou, bez úpravy zdrojových kódů a rozšíření komunikačního protokolu nemáte šanci (jeden skoro skutečný debugger PL/pgSQL jsem už napsal). Když se ale smíříte s určitými omezeními a pokud použijete knihovnu orafce, je tu jistá naděje.

Rok 2005 se zapíše do historie, i do té open source databázové. Firebird2, MySQL5, PostgreSQL8 jsou systémy, které představují významný pokrok vůči předchozím verzím a s trochou nadsázky mohu upřímně napsat, že open source databáze dohonily komerční databázové systémy, které se ovšem zase dostaly někam jinam (kdo ale nepotřebuje OLAP, tak tomu by měly stávající open source systémy vyhovovat).

Článek na Root.cz mě vyprovokoval jednak k úvahám o smyslu srovnávacích testů, jednak k vlastnímu porovnání. Tyto analýzy nejsou tak úplně od věci. Nemají ale sloužit k jalové výměně názorů, který že systém je lepší, ale k diagnostice chyb. Hlavně těch mých. To, jak provádím testy, ukazuje na moje znalosti testovaných systémů, a pokud v testu dělám chybu, mám možnost, že mne na ni někdo upozorní a ukáže mi, jak ji nedělat. A ukáže to i ostatním.