18 komentářů k článku Přechod z MySQL na CouchDB: Druhý díl:

  1. A co XML databáze

    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?

    1. František Kučera

      Re: A co XML databáze?

      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).

      1. Jerry12

        Re: A co XML databáze?

        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.

    2. Radek

      Re: A co XML databáze?

      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 :-)

  2. Jan Semorád

    Objektová databáze

    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…

    1. logik

      Re: Objektová databáze

      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…

    2. MarekB.

      Re: Objektová databáze

      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

      1. Jan Semorád

        Re: Objektová databáze

        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???

    3. alef0

      Re: Objektová databáze

      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.

  3. Pavel Křivánek

    CouchDB a XULRunner

    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.

  4. eL

    Strom

    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í?

    1. Stefan

      Re: Strom

      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((

    2. Karel Minařík

      Re: Strom

      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.)

  5. Jan Semorád

    Zelená je Praxe

    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 :-)

    1. Jiří Kosek

      Re: Zelená je Praxe

      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.

    2. František Kučera

      Re: Zelená je Praxe

      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.

  6. gondo

    horizontalne skalovanie?

    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?

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3441