Webdesignérův průvodce po HTML5: Databáze v prohlížečích

V dnešním dílu našeho průvodce po vymoženostech, které vývojářům webových stránek nabízejí nové technologie z rodiny HTML5, se po oblastech poměrně slušně podporovaných a použitelných dostáváme na nejistou půdu novinek, které budeme moci použít možná za rok, možná vůbec ne. Vítejte ve světě HTML5 databází.
Seriál: Webdesignérův průvodce po HTML5 (21 dílů)
- Webdesignérův průvodce po HTML5 – díl nultý 25. 5. 2010
- Webdesignérův průvodce po HTML5 – nová sémantika 1. 6. 2010
- Webdesignérův průvodce po HTML5 – nová sémantika II 8. 6. 2010
- Webdesignérův průvodce po HTML5 – pohyblivé obrázky 15. 6. 2010
- Webdesignérův průvodce po HTML5 – používáme pohyblivé obrázky 22. 6. 2010
- Webdesignérův průvodce po HTML5 – taháme data od návštěvníka 29. 6. 2010
- HTML5 Audio: rádio ve vašich stránkách 13. 7. 2010
- Webdesignérův průvodce po HTML5: Microdata 20. 7. 2010
- AppCache: webové aplikace i bez připojení 27. 7. 2010
- Webdesignérův průvodce po HTML5: WebStorage 3. 8. 2010
- Webdesignérův průvodce po HTML5: Multithreading s WebWorkers 10. 8. 2010
- Webdesignérův průvodce po HTML5: Databáze v prohlížečích 17. 8. 2010
- Webdesignérův průvodce po HTML5: Shrnutí a rozhrnutí 24. 8. 2010
- HTML5: ukládáme si data k elementům 6. 12. 2010
- Webdesignérův průvodce po HTML5: Táhni a srůstej 5. 1. 2011
- HTML5: První krůčky s FileSystem API 15. 2. 2011
- Mobilizujeme web v HTML5 4. 4. 2011
- Single Page Apps a řešení problémů s historií 1. 6. 2011
- Page Visibility API: Kouká na mě vůbec někdo? 10. 8. 2011
- Práce se soubory v prohlížeči, díl 1 15. 8. 2011
- Práce se soubory v prohlížeči, díl 2 5. 9. 2011
Nálepky:
V předminulém dílu našeho Průvodce jsme si ukazovali Web Storage, které je vlastně jednoduchou key-value databází. Kromě ukládání dat nenabízí nic navíc, a to leckdy nemusí stačit. Proto rodina HTML5 představuje i poněkud komplexnější datové úložiště, které lze už směle nazvat databází. A přesně v dobrých tradicích webových technologií: Nabídneme rovnou dvě databáze, navzájem nekompatibilní, to aby si mohl vývojář vybrat, ve kterých prohlížečích jeho aplikace nebude fungovat.
A teď vážněji: Specifikace databází pro prohlížeč jsou opravdu dvě. První, nazvaná Web Database, vychází z logického předpokladu: Většina dnešních prohlížečů si ukládá data do SQLite nebo podobné databáze, takže umožnit přístup k této databázi přes nějaké API je logické. Druhá specifikace, nazvaná IndexedDB, vychází z neméně logického předpokladu: SQL je pro klienty s JavaScriptem kanón na vrabce, mnohem užitečnější bude nabídnout objektové úložiště s možností indexace dat.
Pokud byste se chtěli přiklonit k jedné nebo druhé straně podle svých sympatií k tomu či onomu prohlížeči či podle stavu implementace, prosím, zde jsou podklady: Web Database podporují Chrome, Safari a Opera. FF ani IE je nepodporují a ani v nejbližších verzích podporovat nehodlají, namísto toho prosazují IndexedDB. Podle jednoho z vývojářů Firefoxu (viz) je Web Database neelegantní, protože jen předává SQL příkazy coby řetězce a přebírá vrácená data, přitom ale nijak nerespektuje vlastnosti JavaScriptu (situace je podobná heterogennímu zapisování SQL příkazů do objektového kódu např. v PHP – pozn.aut.) Problém s IndexedDB je ten, že je implementován zatím jen v betaverzi Firefoxu 4.
Pravděpodobné je, že budoucí vývoj odsune Web Database, kde i specifikace přiznává, že je ve slepé uličce, na vedlejší kolej a přednost dostane IndexedDB. Problém je, že v této oblasti nelze být prorokem: mnohokrát se již stalo, že se nakonec prosadil ten největší outsider na úkor těch technicky vyspělejších řešení – leckdy jen proto, že „už byl“ a vývojáři si na něj zvykli.
Pokud máme být upřímní: Vývojáři si mohou vybrat, jestli použijí Web Database, která se podle všeho nebude moc rozvíjet a zůstane proprietární technologií, ale už funguje, nebo jestli použijí IndexedDB, která má sice podporu odborné veřejnosti, ale zatím nemá použitelnou implementaci. A ačkoli v jiných dílech radíme začít používat nové technologie již nyní, zde opravdu nelze s čistým svědomím doporučit ani jednu z těchto technologií k běžnému použití. Na místě je spíš vyčkat a zatím používat Web Storage.
Web Database
Popišme si nejprve Web Database. Tentokrát nepůjdeme do velkých podrobností a v ukázkách se zaměříme spíš na náznaky práce s touto databází, než na funkční příklady.
Web Database je, jak již bylo řečeno, rozhraní k databázi SQLite. Pokud jste s touto databází již pracovali, dokážete si představit, co vás čeká. A opravdu – kód nepřekvapí (volně dle HTML5 Doctor):
//Připojení k databázi var db = window.openDatabase('mydb', '1.0', 'Database', 2 * 1024 * 1024); //otevřeme transakci, vytvoříme tabulku a naplníme ji daty db.transaction(function (tx) { tx.executeSql('CREATE TABLE IF NOT EXISTS foo (id unique, text)'); tx.executeSql('INSERT INTO foo (id, text) VALUES (1, "HTML5")'); tx.executeSql('INSERT INTO foo (id, text) VALUES (2, "rulez")'); var id = 3; var value = "!!!"; tx.executeSql('INSERT INTO foo (id, text) VALUES (?, ?)', [id, value]); }); //v další transakci vypíšeme data db.transaction(function (tx) { tx.executeSql('SELECT * FROM foo', [], function (tx, results) { //callback funkce, která přebírá výsledky var len = results.rows.length, i; for (i = 0; i < len; i++) { alert(results.rows.item(i).text); } }); });
Příklad ukazuje základní kroky při práci s Web Database. Nejprve je otevřeno spojení funkcí openDatabase(). Ta má čtyři povinné parametry a jeden volitelný. Povinné parametry jsou: Název databáze, verze databáze, popis a velikost v bajtech. Pátý nepovinný parametr je callback funkce, která je zavolána v případě, že databáze s tímto číslem verze neexistuje.
Verzování je totiž u WebDatabase nástrojem, který řeší změny struktury. V nové verzi webové aplikace může vývojář zjistit číslo verze („revize“) databáze, a pokud není aktuální, může provést potřebné změny a přepnout na aktuální verzi pomocí changeVersion
. Podle dostupných informací ale tento postup nefunguje ve všech prohlížečích spolehlivě (v Chrome a Opeře ano, v Safari ne). Možných řešení je několik – buď udržovat „stavovou databázi“, nebo požadovat „dostupnou verzi“ (stačí nastavit číslo verze rovné prázdnému řetězci) a z vlastnosti version
zjistit požadované označení.
Pokud budeme požadovat např. „verzi 3.0“, ale s daným jménem bude dostupná pouze verze „2.0“, dojde k chybě. Pokud nebude žádná databáze toho jména k dispozici, bude vytvořena nová. Je možné používat např. takovýto postup:
//otevřeme dostupnou verzi databáze, nebo vytvoříme novou prázdnou var db = openDatabase('mydb', '', 'Database', 2 * 1024 * 1024); //pokud verze db neodpovídá aktuální, aktualizujeme ji. if (db.version != '1.0') { db.changeVersion(db.version, '1.0', function(tx) { // nastavíme potřebné tx.executeSql('CREATE TABLE foo (id unique, text)'); tx.executeSql('CREATE TABLE bla (id INTEGER PRIMARY KEY, pocet INTEGER, text)'); }); } else { // Databáze je už nastavená a aktuální // ..... }
K vykonání SQL příkazů slouží metoda executeSql
, která má jako první argument SQL příkaz, jako druhý volitelný má pole parametrů (pokud je SQL parametrizované), a jako třetí volitelný má callback funkci pro zpracování vrácených výsledků. Metodu executeSql
nabízí objekt transakce, k němuž se dostaneme v callback funkci, předané metodě transaction()
– viz výše uvedený kód:
db.transaction(function (tx) { ... zde je transakce dostupná jako objekt tx ... });
Existují různé druhy transakcí, k databázi lze přistupovat asynchronně i synchronně, ale zájemce o tyto speciality bych odkázal na specifikaci Web Database.
Uveďme si ještě ve stručnosti důvody, proč je Web Database, i podle své specifikace, ve slepé uličce. Naleznete je přehledně sesumírované v tomto článku. Kromě zásadního důvodu, že specifikace neurčuje SQL a pouze se odkazuje na „implementaci SQLite“, je to především to, že implementace SQL není jednotná a že u dvou velkých tvůrců prohlížečů, totiž Mozilly a Microsoftu, narazil na zásadní odpor (a to i přesto, že např. Firefox interně SQLite používá). Výhradami Mozilly proti Web Database se zaobírá i výše odkázaný článek.
IndexedDB
Kritizovat Web Database je jedna věc, nabídnout alternativu druhá. Má Mozilla alternativu databáze vhodné pro webového klienta? Má, a jmenuje se IndexedDB – dříve známá jako WebSimpleDB. V současné době je její podpora pouze v betaverzích Firefoxu 4. Podle informací prý „Microsoft vidí v IndexedDB budoucnost“ a rovněž Google zvažuje implementaci IndexedDB v Chrome.
Co tedy Mozilla vyčítá Web Database a co podle ní IndexedDB nabízí? Jak jsme si už řekli, není IndexedDB klasickou relační databází, ale v podstatě implementací BTree – tedy navenek objektovým úložištěm, v němž lze snadno vyhledávat a které lze procházet. Jde tedy o úroveň níž než Web Database, a namísto jazyka pro vyhledávání dat v indexovaném úložišti nabízí přímý přístup k tomuto úložišti. Podle zastánců IndexedDB odpovídá přímé ukládání JavaScriptových objektů a úložiště coby objekt duchu jazyka lépe než předávání řetězců se SQL příkazy.
Příklad práce s IndexedDB a srovnání s WebDatabase nabízí An early walk-through of IndexedDB na webu MDC. Zájemce o ukázky odkážu tedy tam.
IndexedDB nabízí pro práci s daty objektové úložiště, které implementuje mnohé vlastnosti, známé ze SQL. Jsou zde „databáze“, v nich „záznamy“, a každý záznam má sadu „polí“. Změny probíhají v „transakcích“. Můžete si vybrat určitou část záznamů podle nějakého kritéria a procházet ji pomocí „kurzoru“. Rozdíl je ten, že toto úložiště nenabízí žádný dotazovací jazyk typu SQL. Nemůžete jednoduše položit dotaz „ SELECT * FROM articles WHERE published=1
“, musíte si vytvořit kurzor pro tabulku articles, projít záznamy o článcích, vyfiltrovat ty, které nejsou publikované, a zbytek předat funkci, která jej zpracuje.
S IndexedDB je práce podobnější např. práci se seznamy, a vývojáři Mozilly mají pravdu v tom, že je konzistentnější se stylem programování v JavaScriptu a koncepčně zapadá spíš než SQL dotazy a jejich zpracovávání.
Závěr
S databázemi v prohlížečích je to v současné době neveselé. Je tu SQL WebDatabase, podporovaná minoritními prohlížeči, ale její budoucnost je nejistá a stavět na ní aplikaci, už jen kvůli marginální podpoře, nelze. Je tu IndexedDB, ale ta je ve stádiu technologického dema. Možná bude za rok použitelná, v současné době ale rovněž použitelná prakticky není.
Pokud tedy potřebujete ukládat data v prohlížeči, budete si muset vystačit s Web Storage, které je ale naštěstí poměrně rozšířené. Na lepší si budeme muset počkat.
Čtení k tématu:
- Specifikace WebDatabase
- Specifikace IndexedDB
- Introducing Web SQL Databases
- Web Database demonstration
- persistence.js, „Asynchronní JavaScript ORM” postavený nad Web Database a Gears
- Beyond HTML5: Database APIs and the Road to IndexedDB
- Firefox 4: An early walk-through of IndexedDB
- Dive into HTML5 – Local Storage
- Ukázka práce s IndexedDB
- IndexedDB na Google Code
- Web SQL database demo
a kde to využijem okrem intranetov? veď to ešte nepodporujú všetky browsery, btw neni lepšie pracovať priamo so serverovou DB cez ajax?
Přesně tak, píšu o tom v článku (a ani v intranetu bych to asi nenasadil). Berte informace spíš jako ukázku současného intenzivního dění v této oblasti. Dnes (a asi i v nejbližší budoucnosti) je práce se serverovou DB via AJAX asi rozumnější. Mimochodem, tuhle zajímavost znáte? http://zdrojak.root.cz/zpravicky/couchapp-web-primo-z-databaze-bez-http-serveru/
neznám, ale vďaka za info
Ano i ne. Jeden z cílů těchto databází je podpořit práci offline. Třeba GMail tak může do takové databáze natahat maily a vy k nim pak máte přístup i offline, jakmile se připojíte začne zas tahat data z databáze na serveru. (Né že by to tak dělal, nebo o tom alespoň nevím, jen jsem se snažil ukázat možnost využití).
Jinak je podle mě hloupost odsuzovat jednu či druhou databázi. Obě se můžou hodit a podle mě by se měli pánové od prohlížečů dohodnout, že všichni implementují všechno a ať si vývojáři zvolí co uznají za vhodné.
No gmail přesně takhle pracovat umí. Akorát k tomu doteď používal databázi z Google Gears.
Zkoušel jsem to a fungovalo to dobře. Časem jsem ovšem Gears potratil, na počítačích jsem online pořád a na rychlé lince. U mobilních zařízení je to o něčem jiném.
GMail webová aplikace pro iPhone Web databázi v Safari používá. Vůbec, na iPhone je to cesta jak vytvářet off-line webové aplikace s „custom“ cachováním (v kombinaci s AppCache manifestem).
Tak z tou domluvou vývojářů prohlížečů jsi to myslel vážně ? Bylo by to fajn. Rovnou, když už budou sedět u jednoho stolu, by se mohli domluvit a všichni stejně implementovat html a kaskády :D
Myslím, že lidé od Mozilly to vzali s IndexedDB za správný konec, a je mi jich líto, že se na ně v odkazovaných článcích na hacks.mozilla.org snáší taková tvrdá kritika. Problém zní, jak ukládat data na klientovi. Jeden extrém je plně vybavená databáze s jedním modelem dat (relační databáze, jak ji specifikuje Web SQL Database), druhým extrémem by bylo dát na klientu přístup k souboru a celou databázi ať si vývojář napíše sám.
IndexedDB je kdesi uprostřed – poskytuje funkce, které by bylo otravné implementovat (ukládání, výběry, indexy…), avšak nevnucuje vývojáři relační model dat (jako WebSQLDb).
A jak vývojáři Mozilly píší: „We’d particularly welcome an implementation of the Web SQL Database API on top of IndexedDB […]“ Bohužel spoléhat na to, že to udělá někdo jiný, se mi nezdá dobré. Kdyby řekli: „Jo, WebSQLDb se nám nelíbí. Tady máte IndexedDB. Ale abyste tedy mohli používat WebSQLDb, my ji implementujeme nad IndexedDB,“ situace by byla ideální (v případě, že by IndexedDB nepoužívala jako úložiště SQLite), poněvadž WebSQLDb specifikace se dostala do slepé uličky hlavně kvůli tomu, že SQLite je dost dobrá na to, něž aby někdo chtěl implementovat jiný backend pro WebSQLDb. Specifikace z rodiny HTML5 potřebují alespoň dvě nezávislé (jestli si pamatuji dobře) implementace, aby se mohli posunout dále. WebSQLDb čeká, až někdo další implementuje její API nad něčím jiným než SQLite. Mohla by to být právě Mozilla s IndexedDB.
Díky za doplnění a upřesnění.
Implementovat SQL nad IndexedDB, kteréžto by interně používalo SQLite, je svým způsobem poetické :-)
Já si vždycky říkal, že pro tebe je nejvíce poetická perverze.
Mne pride nazor Mozilly na SQlite troska nestastny. A to z toho dovodu, ze SQlite je deklarovanym úložišťom v Adobe AIR aplikaciach. AIR devels si uz na jeho API zvykli, je okolo toho kopec JS kniznic (jednoduche ORMka v JS) a toto vsetko sme teraz mohli mat v browseroch. Myslim, ze ich cesta nie je nastastnejsia.
Pozici Mozilli a MS považuji za ohromně nešťastnou, do diskuze na Mozilla Hacks jsem se i zapojil… Důvody tam zmíněné jsou směšné v porovnání s tím, co by relační databáze v prohlížeči mohla nabídnout. A na rozdíl od p. Malého bych ji například do intranetu rozhodně nasadil (nic osobního, jenom nesouhlasím :)). Minimálně v intranetu je možné diktovat podmínky na browser. A ani u web aplikace bych se tomu nebránil, prohlížeč je prostě runtime (málokdo má problém s tím si naistalovat Javu, nebo .NET).
Problém s IndexedDB je krásně vidět právě na Mozilla Hacks, kde jsou ukázky, jedna věc je mít objektové úložiště, druhá věc jsou dotazy spojující objekty (SQL joiny), ten příklad tam jasně ukazuje utrpení, kterým budou programátoři procházet. Implementace SQL nad IndexedDB je pouze a jenom teoretická možnost. BTree umí naprogramovat skoro každý, udělat klíčování více položek, joiny, triggery, apod. a především optimalizace je práce na léta, stačí se podívat, kolik vlastně použitelných DB serverů existuje.
No co, ale je to Mozillí volba, vývojáři si také vyberou :)
P.S. nemám rád konspirační teorie, ale MS má MSSQL, Mozilla úzce spolupracuje s Oracle… nasazení SQL do prohlížeče se jim asi moc nelíbí :)
Neberu to osobně, vůbec ne, a stručně vysvětlím, proč bych to dnes nenasadil ani na aplikaci určenou pro intranet:
1. V intranetu nechápu moc potřebu offline úložiště – krom specifických případů „intranetu přes VPN“ apod. je připojení permanentní, navíc záměrem intranetu je většinou mít pro všechny stejná data…
2. Sáhnul bych, když už, spíš k Web storage – SQL mi v intranetovém klientu připadá jako overkill (proč se nekomunikuje po lince rovnou se serverem?)
3. Pamatuju se na intranety postavené nad „unikátními možnostmi, které nabízí IE4“ a „vyžadující IE5“ co jsou dnes jako koule na nohách, kvůli kterým musí firma řešit instalace specifických verzí IE apod.
4. Systém, byť pro intranet, postavený na takhle okrajové technologii, je prakticky neprodejný jinam.
Takže použitelné by to bylo snad v případě intranetu pro vlastní použití (a nikde jinde), distribuované jako speciální aplikace (zástupce Chrome na ploše apod.), v situaci, kdy často padá spojení nebo server a nelze to řešit jinak, a pro aplikace, které z nějakého důvodu potřebují dělat komplexní operace nad lokálním úložištěm. Po pravdě si takovou nedovedu moc představit.
A ad utrpení: Ano, přesně tak. Když jsem koukal na tu ukázku JOIN v IndexedDB, tak jsem se zhrozil a předem litoval ty, co v tomhle budou muset vyvíjet
Chápu, ale myslím, že váš pohled vychází právě z pohledu na prohlížeč jako na prohlížeč :). Můj pohled opravdu vychází z použití prohlížeče jako application runtime. Běžně se píší firemní aplikace vyžadující JRE nebo .NET, a dobře se používají, stejně tak si myslím že je toto možné i s prohlížečem, jediný problém je překonat ono paradigma prohlížeče (http://www.webnt.cz/12-web-aplikace-ne-aplikace/). Aplikace běžně pracují v modu lokální data, synchronizace se serverem a k tomu by byla WebDB úpně dokonalá, na obou stranách stejné schéma, jednalo by se pouze o reflexe ServerDB ↔ ClientDB. Ano tato reflexe by byla možná i pto IndexedDB nebo Storage (stejně si ze serveru nebude nikdo generovat SQLka, které pak provede na klientovi), ale ani jedna s těchto variant nepřináší možnosti relací, dotaz přes 3 objektové struktury prostě bez SQL prostě zabije každého :)
Pokud budu DNES psát takovou aplikaci, napíšu ji spíš jako nativního tlustého klienta v běhovém prostředí, které je primárně určeno pro psaní nativních klientů s databází a UI, a ne v prostředí, které… atd. Ne?
Ano, takto píšu desktopové aplikace běžně, ale začínám se čím dál tím více přiklánět právě k prohlížeči. Jasně, existují aplikace, které bych pro prohlížeč nepsal, Delphi mi poskytnou MNOHEM více možností, ale pokud zvažují nejběžnější požadavky alespoň zákazníků, které mám, zjišťuji, že prohlížeč stačí a dokonce může některou práci ušetřit. Jediné, co mi tam teď chybí pro nejběžnější požadavky, je UI, ovládací prvky, ale to už vyřeší canvas :)
Ale ano, shodneme se na tom, že pokud ji budu psát dnes, napíšu nativního klienta, ale mám za to, že použití prohlížeče je otázkou měsíců, nikoliv let.
Takže shoda je úplná… Není spor, jen rozdílný úhel pohledu. :) I já psal, že si na opravdu použitelnou technologii budeme muset nějaký čas počkat.
Jen dodávám, že ani pro intranetové app mi zatím (!) nepřijde rozumné se do využití WebDB nějak hrnout, protože bůhví jak to s nimi bude dál a mohli bychom se dočkat instalací různých „sandboxed“ prohlížečů jako runtime… To už bych asi raději zvolil třeba AIR – viz http://zdrojak.root.cz/zpravicky/vytvareni-desktopovych-aplikaci-v-html-s-air/
Ano, je fakt, že čekám, než někdo z WebKitu udělá COM komponentu, abych ji mohl obalit normálním oknem a nevypadalo to jako prohlížeč, a HTML a JS a CSS zdrojáky si zakompilovat do exáče jako resources :)
Zase něco vymýšlejí když něco je a funguje ….. to připojení do db je taky výborný
var db = window.openDatabase(‚mydb‘, ‚1.0‘, ‚Database‘, 2 * 1024 * 1024);
no mikrosoft jako by nestačil stará známý způsob
$connect = mysql_connect($server, $login, $heslo);
kolik toho ještě budou chtít vymyslet?