Přejít k navigační liště

Zdroják » Databáze » Přechod z MySQL na CouchDB: Druhý díl

Přechod z MySQL na CouchDB: Druhý díl

Články Databáze

V předcházejícím článku jsme si ukázali základy toho, jak pracuje MySQL a CouchDB, porovnali jsme postupy jak modelovat data, a také jsme si ukázali, jak fungují základní dotazy a seznamy záznamů, a to jak pomocí SQL dotazů v MySQL, tak i s použitím pohledů (view) v CouchDB.

Nálepky:

Disclaimer: Článek je překladem článku How to move from MySQL to CouchDB, part II z blogu CouchOne. Překlad i s originálními ilustracemi vychází s laskavým svolením společnosti CouchOne. Autor článku pracuje v CouchOne jako člen výboru a viceprezident pro dokumentaci, v minulosti psal dokumentaci k MySQL. Minulý týden vyšel překlad první části.

Tentokrát začneme tím, že si ukážeme, jak zadávat tyto pohledy a určité další prvky SQL dotazů, jako jsou klauzule WHERE a GROUP BY, a podíváme se na vlastní postup přenosu dat a aplikační logiky na CouchDB.

Zamyslete se nad dotazy, které budete provádět

Jak jsme už viděli, tvorba dotazů na CouchDB se ve skutečnosti skládá ze dvou kroků. Prvním z nich je vytvoření pohledu, který umožní vyhledávání a vybírání dokumentů v databázi. Druhou částí je URL a hodnoty klíče, které chceme z pohledu vybrat. To znamená, že při plánování, jak získat data z CouchDB databáze, je potřeba si promyslet, podle čeho budete data vyhledávat, a to vám pomůže určit strukturu pohledu, který bude potřeba vytvořit.

CouchDB používá pohledy k vytvoření seznamů dokumentů z databáze, a výstupem pohledu je klíč a k němu příslušná hodnota. Jak klíče, tak i tyto hodnoty mohou mít formu jakékoliv JSON hodnoty. Klíč je ve výstupu podstatný proto, že je základem pro mechanismy vyhledávání, třídění a stránkování.

Například funkce vytvářející pohled, který vrátí všechny dokumenty receptů z databáze, jejichž klíčem bude název receptu, by mohla vypadat takto:

function(doc) {
    if (doc.type == 'recipe' &&
        doc.title !== null) {
        emit(doc.title, doc);
    }
}

Takovéto funkci se říká mapovací funkce – mapuje údaje z dokumentů na formát, který má být použit. Nepovinný druhý krok se nazývá reduce, a je obdobou agregačních funkcí a klauzule GROUP BY v MySQL. (Jde o známý algoritmus map/reduce – pozn.překl.)

Při přechodu z MySQL bude mít vliv na to, jak budete data ukládat, i samotný návrh pohledů. Ty navrhujeme tak, aby odpovídaly datům, která chcete vypisovat nebo se na ně dotazovat. Vraťme se k našemu příkladu s recepty: na MySQL byste sestavili dotaz, který hledá mrkev v tabulce přísad, a získali byste tak seznam nalezených receptů. Ve formě SQL by vypadal takto:

SELECT recipe.id, recipe.title FROM ingredients join (recipe) on
    (ingredients.recipeid = recipe.id) where ingredient = 'carrot'

V CouchDB lze stejného výsledku dosáhnout vytvořením pohledu, který vrátí jeden řádek pro každou přísadu z našeho dokumentu s recepty takto:

function(doc) {
    if (doc.type == 'recipe' &&
        doc.title !== null) {
        for id in doc.ingredients {
              emit(doc.ingredients[id].ingredient, doc);
         }
    }
}

V dotazovém URL, které slouží pro zpřístupnění pohledu, byste pak zadali požadovanou hodnotu klíče, v našem případě mrkev. Například:

http://couchdb:5984/recipes/_design/recipes/_view/by_ingredient?key=%22carrot%22

Nezapomínejte, že klíčem může být jakákoliv hodnota JSON, a hodnoty klíče, které do dotazu zadáváte, musí být tedy správně enkódované. Jak je vidět z tohoto příkladu, pohled tvoří základ dotazu a samotný přístup k vyhledávání je v režii databáze.

Používání pohledů tímto způsobem vede k tomu, že většina aplikací bude nakonec tvořena mnoha různými pohledy. Postup vytváření pohledů se přitom vlastně neliší od tvorby základních dotazů v aplikaci, a následné optimalizaci těchto dotazů a indexů pro vrácení požadovaného výstupu. Hlavní rozdíl je v tom, že definice pohledu není dotazem v aplikačním kódu, ale je uložena v databázi.

Agregace

V MySQL se agregace (seskupení) používají na mnoha různých místech. Agregace je dosaženo kombinací klauzule GROUP BY a funkcí, které shromažďují či shrnují údaje. V našem příkladu s recepty můžeme provést dotaz, který vrátí ke každé přísadě počet receptů, v kterých je obsažena. Například dotaz:

SELECT ingredient,count(recipeid) FROM ingredients GROUP BY ingredient

vrátí seznam přísad a ke každé z nich počet receptů, do kterých daná přísada patří. Ve výsledné aplikaci se takto mohou objevit „nejčastěji používané přísady do receptů“, v jiných aplikacích to zase mohou být „nejoblíbenější příspěvky na blogu“, apod.

V CouchDB se k seskupení použije reduce funkce. Navazuje na původní mapovací funkci a zúží výsledky, které mapovací funkce vrátí.

Rozšíření dotazů

Složitější dotazy, při nichž se vyhledává ve podle více datových položek, jsou jen otázkou vytvoření vhodného pohledu, a pak správného zadání hledaných údajů v parametrech dotazu jako vyhledávacího klíče. Pokud mají být vráceny jen údaje v určitém rozmezí, lze použít k zadání tohoto rozsahu počáteční a koncový klíč. Pokud si například vytvoříte pohled, jehož klíčem bude čas přípravy jednotlivých receptů, získáte z něj seznam všech receptů, jejichž příprava zabere 5 až 25 minut, takto:

http://couchdb:5984/recipes/_design/recipes/_view/by_cooktime?startkey=%225%22&endkey=%2225%22

Jedná se o obdobu dotazu:

SELECT title FROM recipe WHERE cooktime >= 5 AND cooktime <= 25

Seřazení výsledků

Řazení výsledků se provádí automaticky podle klíče generovaného každým pohledem. Pokud tedy chcete vypsat seznam receptů seřazených abecedně podle názvu, stačí si vytvořit pohled, který vrací jako klíč název receptu. To znamená, že

http://couchdb:5984/recipes/_design/recipes/_view/by_title

je obdobou

SELECT title FROM recipe ORDER BY title

Pro seřazení výsledků sestupně se v MySQL použije klíčové slovo DESC

SELECT title FROM recipe ORDER BY title DESC

V CouchDB se v URL zadá parametr descending

http://couchdb:5984/recipes/_design/recipes/_view/by_title?descending=true

Stránkování

V MySQL lze dosáhnout stránkování pomocí kombinace klauzulí LIMIT a OFFSET, například takto získáte prvních deset záznamů z našeho dotazu na názvy receptů:

SELECT title FROM recipe ORDER BY title LIMIT 10

Dalších 10 záznamů:

SELECT title FROM recipe ORDER BY title LIMIT 10 OFFSET 10

V CouchDB se používá podobný postup, kdy se limit a skip zadávají jako parametry dotazu. Prvních deset záznamů tedy získáte takto:

http://couchdb:5984/recipes/_design/recipes/_view/by_title?limit=10

A dalších 10 záznamů:

http://couchdb:5984/recipes/_design/recipes/_view/by_title?limit=10&skip=10

Načtení celého základního objektu

V ukázkové databázi receptů v MySQL je potřeba pro zobrazení jednho receptu načíst údaje z více tabulek. V CouchDB platí, že jakmile máte ID dokumentu daného receptu, tak máte přístup k celé struktuře záznamu o tomto receptu tak, jak byl do databáze uložen.

Potřeba zjednodušit mechanismus načítání takovýchto složitých objektů vedla u MySQL k mnoha různým pomocným projektům, které mohou pomoci zvýšit dostupnost dat (např. jejich cachováním v paměti). I při použití CouchDB zůstává nutnost načíst údaje z databáze, ale načtení celého záznamu receptu je možné v rámci jedné operace, namísto několika dotazů a převedení dat do struktury použité pro jejich zobrazení.

Jakmile máte ID dokumentu, stačí k získání obsahu celého dokumentu v CouchDB jediná operace. Pokud například získáte ID dokumentu Aromaticroastchic­ken z našeho pohledu podle přísad, lze pak celý dokument receptu zobrazit pomocí jediného web requestu:

GET http://couchdb:5984/recipes/Aromaticroastchicken

Výsledkem jsou data receptu jako JSON:

{
   "title" : "Aromatic roast chicken",
   "preptime" : "15",
   "servings" : "6",
   "totaltime" : "120",
   "subtitle" : "A couscous stuffing, and aromatic spices with fragrant lime and roasted garlic, turn a simple roast chicken into something special.",
   "cooktime" : "105",
   "_id" : "Aromaticroastchicken",
   "_rev" : "1-c76ba47a4848af8f965d3940efb118df"
    "keywords" : [
      "diet@dairy-free",
      "cook method.hob, oven, grill@oven",
      "diet@peanut-free",
      "special collections@cheffy recommended",
      "diet@corn-free",
      "special collections@weekend meal",
      "occasion@entertaining",
      "special collections@very easy",
      "diet@yeast-free",
      "diet@shellfish-free",
      "special collections@feeling spicy!",
      "main ingredient@poultry",
      "diet@demi-veg",
      "meal type@main",
      "diet@egg-free",
      "diet@cow dairy-free"
   ],
 "ingredients" : [
 ...
   ],
 "method" : [
 ...
   ],
}

Stačí jeden dotaz, jeden požadavek na databázi, aby vrátila vše potřebné pro zobrazení celého receptu na stránce. Samozřejmě zde může být zahrnutý i další obsah, jako komentáře uživatelů nebo další metadata, vše uložené v jednom dokumentu, dostupné pomocí jednoho dotazu.

Přesun dat

Výstupní formát dat je základem pro další závažné rozhodnutí související s přechodem. Je třeba vzít v potaz, jak se bude s údaji pracovat. Pokud jsou údaje, které pochází v MySQL z více zdrojových tabulek, zobrazovány najednou, mívá smysl sloučit tyto informace a ukládat je v CouchDB jako jeden dokument.

Jak už bylo uvedeno, mnoho urychlujících mechanismů, používaných ve spojení s MySQL, funguje na základě toho, že si cachují data z více tabulek, jakmile byly jednou načteny, a tím urychlují nahrávání komplexních datových struktur.

Stejný princip platí i v CouchDB, pokud vezmeme v potaz výše zmíněné pravidla omezující strukturu. Pokud chcete podle určitých kritérií získávat dokumenty z databáze, musíte zajistit, že  struktura dat dovoluje vytvořit pohled umožňující vyhledávání.

Například ve struktuře našeho receptu nemá smysl ukládat přísady jako jediné textové pole a tím ztratit podrobnosti o obsahu. To je obdobou uložení všeho do jediného textového sloupce v MySQL a vede ke stejným problémům: zhoršuje možnosti vyhledávání a dotazování podle těchto údajů, a omezuje možnosti zobrazení dat.

Samotný postup přesunu dat je vcelku jednoduchý – načíst data z MySQL databáze, vytvořit dokument pro každý hlavní objekt v databázi, a pak tyto dokumenty zapsat do CouchDB databáze.

Dokumenty v CouchDB jsou ukládány podle svého ID. ID může být libovolný řetězec, což znamená, že můžete použít jakýkoliv údaj jednoznačný pro vás nebo vaší aplikací bez toho, abyste ho museli tento hledat v některém pohledu. V naší všudypřítomné databázi receptů byste takto mohli použít název receptu, například „Rybí polévka“. Omezením tohoto přístupu (stejně jako unikátních indexů v MySQL) je, že nelze uložit dva dokumenty se stejným ID.

Stejně jako funguje klauzule AUTO_INCREMENT v MySQL, tak i CouchDB dokáže vygenerovat automaticky UUID pro každý nový dokument. To ale není povinné, takže můžete mít v jedné databázi jak dokumenty s konkrétním ID, tak i s automaticky vygenerovaným ID, což umožňuje přiřadit předem zvolená ID význačným instancím a dokumentům, a pro zbývající data použít automaticky generované ID.

Rozhraní k CouchDB

MySQL se nepoužívá jen ve webových aplikacích, a já zde nebudu tvrdit totéž ani o CouchDB, ale stojí za to si zapamatovat, že přístup ke CouchDB probíhá pomocí webového rozhraní, které je založené na koncepci REST. Dokumenty jsou načítány za pomocí URL, a možnosti pohledů a dotazů se zadávají jako parametry tohoto URL, stejně jako u jiné CGI nebo podobné webové aplikace.

Pro většinu programovacích jazyků a platforem jsou k dispozici rozhraní, které zjednodušují postup ukládání informace v databázi CouchDB. Existují nástroje pro Perl, Python, Javu, PHP a mnoho dalších. I pokud dojde k nepravděpodobné situaci, že pro vámi vybranou platformu nebude existovat vhodná knihovna, postačuje ke komunikaci s CouchDB pouze schopnost provádět HTTP dotazy.

U většiny webových aplikací v rámci obvyklých platforem, obzvláště pokud používáte AJAX, vypadá postup dotazování dost podobně jako na následujícím obrázku. Váš dotaz pochází z jQuery, je zpracován aplikací, která komunikuje s MySQL databází a vrátí správně údaje v požadované formě.

Při používání CouchDB můžete část aplikační logiky přesunout na samotnou CouchDB databázi, když pomocí návrhových dokumentů získáte data ve správném formátu už z CouchDB.

Když si vše shrneme

Hlavním rozdílem mezi CouchDB a MySQL je to, v jaké podobě jsou data uložené a jak se k nim přistupuje. Pro určité datové struktury poskytuje CouchDB jednodušší řešení problému načtení dat celého jednoho objektu, jak jsme to viděli v předcházejících příkladech. Recepty jsou pěkným příkladem, kde hlavním prvkem báze dat je recept jako celek (náš dokument). Potřeba vyhledávat údaje o receptu a zobrazovat seznamy je požadavkem pouze na prezentaci dat, nejde o přímý požadavek na to, jak mají být data uložená.

Snad vám tyto dva příspěvky daly určitou představu, jak lze přesunout data z MySQL na CouchDB a jak modelovat data v CouchDB a vyvíjet aplikační kód tak, aby celý systém fungoval stejně jako ve vaší existující aplikaci založené na databázi MySQL.

Komentáře

Subscribe
Upozornit na
guest
18 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
A co XML databáze

A co XML databáze? Dají se snadno prohledávat a pokud to dobře chápu, tak schéma také nemají… Vždyť místo JSON se prostě použije xml…
Nebo se mýlím?

XML databáze můžou a nemusí mít schéma. Navíc můžeš mít i XML v relační databázi (pokud ho podporuje) a mít výhody jak relačních DBMS, tak volných resp. předem neznámých datových struktur (XML), případně složitých známých struktur (XML se schématem).

Jerry12

Osobne nejsem velkem zastance XML, protoze ma velikej overhead a z moji zkusenosti, pokud mezi sebou komunikujou dve aplikace pomoci XML, tak nikdy neni struktura takova jako by mela bejt (od problemu s charsetem pres spatnej navrh az po nevalidnost proti vlastnimu DTD/Schema). Uz jsem videl vazne strasny veci. Bohuzel urcita nezanedbatelna cast byla zprasena ani ne tak kvuli neschopnosti, ale kvuli narocnosti XML na zpracovani. V tomhle smeru je JSON sikovnejsi, protoze tech 10% moznosti vetsine lidi staci a na rychlosti proste zalezi.

Radek

To se nemýlíte, nějaké takové představy asi kdysi stály u vzniku XML databází. Až na to, že u XML ten vývoj už dospěl kousek dál. Pro úplnost, koncept databáze s hierarchicky organizovanými daty už používal např. MUMPS v roce cca. 1966. To jsou objevy :-)

mizsha

jak je na tom couch se stromama ?

a prava uzivatelu a roli na entity, vetve ?

Jan Semorád

Na objektové databáze jsem se těšil řadu let. JSON má oproti XML výhodu v tom, že je konvertovatelný na objekt. Je to vlastně serializace a deserializace objektu. Něco obdobného můžete s XML přímo (pokud vím) pouze ve VB.NET. VB.NET alení fukcionální jazyk – jako je JS. Pokud máte na mysli DOM, tak to jsme na tom vlastně stejně jako s relační tabulkou. Dotaz na relační tabulku vrací recordset. Dotaz na XML/DOM) vrací nodeset. Recordest ani nodeset ale neni objekt srovnatelný s objektem, který dostanu z JSON. Síla jazyka JS (funkcionálnost, dynamičnost etc…) je tu navíc. XML/DOM má sice jednu – a to velkou – výhodu. Jazyk XPATH apod. Tedy dotazovací jazyk, který je velmi silný. Tedy výhodu XML spatřuji v možnosti použít XPATH. XPATH je proti SQL úplně jiný kalibr. Jenže JSON je chytlavější. Místo XPATH se vytvoří dotazovací funkce. Díky síle JS a objektovosti JSON to není vůbec „strašné“. A pak – JSON je pro člověka přece jenom čitelnější než XML…

logik

Ehm, o co je XPATH silnější než SQL? (a to nemluvím o možnosti definice stored procedur).
Další věc je, že na rozdíl od dotazovací funkce, kterou musí optimalizovat programátor, je SQL optimalizováno automaticky.

XML serializovat a deserializovat do XML můžete v X jazycích, PHP nevyjímaje.

A konečně – kdy už lidi přestanou srovnávat SQL a noSQL, když jde o technologie naprosto se lišící jak filosofií, tak i vhodností na různé úkoly…

MarekB.

No-SQL ale nejsou objektové databáze. Respektive jejich současné realizace k nim mají velice daleko (nepodporují dědičnost, polymorfismus atd.).

No-SQL databáze jsou dokumentové databáze a umí ukládat data ve formátu JSON.

Pokud chcete opravdovou objektovou databázi, na wiki si můžete vybrat

Jan Semorád

Souhlas, pokud chceme srovnávat důsledněji, je třeba definovat terminologii. Líbí se mi pojem dokumentová databáze. Dokument je sice také objekt, ale od objektové databáze asi čekáme více. Konkrétně třeba já od ní chci (krom jiných věcí) „object linking“, nativnost a kvalitní query. Proto jsem se zhlédl v DB4O. Pokud ukládáme objekty přes JSON, tak asi budeme dlouho (ne-li trvale) limitováni na „object embeding“. U dokumentů to vadit nemusí, někdy to může být i výhoda(!), například pro ukládání verzí(historie, logu) – uloženou verzi nikdo a nic nezmění (datawarehouse jak višeň). Ještě jedna věc mi fascinuje: stejný (identický) formát pro úložiště, pro transport (komunikaci), pro GUI… Bylo tohle vůbec někdy???

alef0

XPath nie je silnejší než SQL. XPath je adresovací jazyk, takže výsledkom je stále len podstrom, resp. sada uzlov z pôvodného podstromu. XPathom nemôžete pridávať nové uzly, nemôžete odstraňovať, nemôžete prehadzovať ich hierarchiu. Na tieto úlohy je XQuery alebo XSLT.

Pavel Křivánek

Zkoušel jsem CouchDB použít s frameworkem XULJet (http://code.google.com/p/xuljet/) a jedná se docela šikovnou kombinaci. XULRunner neomezuje cíl ajaxových požadavků, takže s databází může komunikovat přímo klient, jdou v něm snadno dělat „líné“ tabulky (https://developer.mozilla.org/en/XUL_Tutorial/Custom_Tree_Views), takže zobrazení téměř libovolně velkého počtu záznamů není problém, na všechno se používá JavaScript (definice pohledů, dotazy, popis GUI…), takže není potřeba žádné ORM atd.

eL

Tak to vypadá, že 2. díl je i poslední díl. Ale to, co mě zajímalo nejvíc stále nevím.

Kdybych chtěl teď ty recepty uložit do kategorií, a jedna část stromu by byla podle národní kultury, druhá podle diet a třetí podle cenové skupiny (tedy prostě jeden recept ve více kategoriích), tak jak to bude vypadat? Jak se v tom bude hledat? A jak to bude efektivní?

Stefan

Přiznám se že také cítím zklamání, takhle jednoduché řešení jaké zde bylo prezentováno se dnes většinou „vygeneruje“ nad DB skoro samo, včetně administrace i stránek prohlížecích. Stále jsem nikde nenašel ty super výhody které všichni vyzdvihují :O((

Karel Minařík

Nevím, jestli rozumím „zadání“, ale pravděpodobně jen tak, že k dokumentu přidáte pole s kategoriemi:

"title" : "Cheese Tortilla",
...
"categories" : [ "mexican", "vegetarian", "cheap" ]
...

a podobně jako autor prochází `for id in doc.ingredients` budete procházet `for id in doc.categories.` Ptát na mexická jídla se budete stejně, jako on se ptá na mrkev.

(Otázce „jak to bude efektivní“ vůbec nerozumím, nechávám ji tedy bez komentáře.)

Jan Semorád

Zdravím všechny.
Během chvilky jsem CouchDB rozběhal podle návodu na WinXP CZ. Poznal jsem v minulosti Informix, Oracle, IBM, MS, MySQL, SQL602 a jiné. Ale poslední roky mi uchvacuje DB4O a teď i CouchDB.
Debaty zde na to se mi líbí. Ale CouchDB je prostě nový, svěží vítr. Bez problémů ukládám do CouchDB názvy attributů (proměnných) v češtině. A mohou být víceslovné. Kam se na to hrabou názvy tagů XML… Hodnota atributu v XML je STRING. V CouchDB to může být objekt (a tedy cokoliv :-) ). Tohle v XML není legrace. Pokud si myslíte, že ano, tak nahlédněte do stránek MS Sharepoint. To není vina Sharepointu, prostě XML je XML… „CamelCase VS Hungarian notation, which is better?“ Tak už máme odpověď.
Srovnávání asi nemá příliš cenu. Asi ani CouchDB nebude všelék na všechno. Jedno však je jisté: zaplňuje jednu – a dost velkou – díru ve světě DB. Docela bych řekl, že v CouchDB může narůst velká konkurence nejen klasickým DB ale i MS InfoPath nebo Altova Authentic…
Svět se ale mění postupně – a i zde to asi nebude jiné… Hlavně se mění paradigmata. A mně třeba přijde rozumnější provozovat search(&index) engine samostatně a necpat ho do funkčnosti DB. To samé s authentizacemi a authorizacemi. To spíše patří do Aplikačního serveru atd… DB nechť je DB. Dnešní DB umí leccos – a data nakonec jak za krále klacka… To to radši otočím, ať DB umí pořádně to, co má dělat – a zbytek deleguji tam, kam náleží. Moje babička říkávala: za jednoho strakatého deset malovaných :-)

Jiří Kosek
Bez problémů ukládám do CouchDB názvy attributů (proměnných) v češtině. A mohou být víceslovné. Kam se na to hrabou názvy tagů XML

V XML mohou být názvy tagů samozřejmě také česky. Mezery v názvech být nemohou, otázkou je, zda je to nevýhoda. Když byste si XML mapoval na objekt, neznám moc jazyků, které by ve svých identifikátorech dovolovaly mezery.

Hodnota atributu v XML je STRING. V CouchDB to může být objekt (a tedy cokoliv :-) )

Atributy v XML mohou mít mnoho dalších typů — číslo, datum, … A proč se omezovat na atributy, máme elementy a ty mohou mít další podelementy. Takže v XML můžete reprezentovat cokoliv. Rozdíl je v tom, že JSON nabízí jedno konkrétní mapování na typový systém programovacího jazyka — pro obecné XML takových mapování existuje více — což může být výhoda i nevýhoda.

Pokud si myslíte, že ano, tak nahlédněte do stránek MS Sharepoint. To není vina Sharepointu, prostě XML je XML...

No zdá se, že Sharepoint pro vás byl opravdu silný zážitek. Než budete zatracovat XML jako datový model pro dokumentově orientované úložiště, doporučil bych vyzkoušet nějakou solidnější XML databázi jako je třeba MarkLogic.

František Kučera

Ad „Hodnota atributu v XML je STRING. V CouchDB to může být objekt (a tedy cokoliv :-) ). Tohle v XML není legrace.“

Tady asi někdo nepochopil XML. Atributy jsou relativně speciální záležitost – normálně se používají elementy a do nich vnořené další elementy, což umožňuje zachytit právě ty složité struktury. Má to celkem blízko v objektům v OOP a dá se to na ně i snadno mapovat.

gondo

ako jeden z hlavnych dovodov prechodu na nerelacne databazy sa casto uvadza skalovatelnost. avsak patrilo by sa zmienit, ze podla vsetkeho CouchDB nieje samo o sebe horizotnalne skalovatelne. na to je potrebne zapojit do hry dalsieho hraca, ci uz BigCounc alebo Pillow alebo nieco podobne. chcem sa preto spytat ci sa planujete venovat aj tomuto?

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.