Komentáře k článku

MySQL v roli neschémové databáze

Neschémové databáze (pro které se vžilo označení „NoSQL“) jsou stále populárnější. Vývojáři začínají často narážet na omezení relačních databází, jejichž návrh je sice časem ověřený, ale přece jen poněkud staršího data. Pojďme se podívat na zajímavý příklad netradičního využití MySQL ve službě FriendFeed.

Zpět na článek

155 komentářů k článku MySQL v roli neschémové databáze:

    1. Martin MalýAutor příspěvku

      Re: Další zdroje?

      Pokud na něco narazím, určitě se podělím.

      Na Zdrojáku se budeme NoSQL databázím věnovat i nadále, na webu má tento koncept budoucnost, takže tohle určitě nebyl ojedinělý článek. Zájemci o toto téma tu rozhodně budou mít co číst i v budoucnu.

  1. keff

    Díky

    Díky za výborný nález (a překlad který nerve uši :)), tohle je nejlepší case study pro NoSQL co jsem zatím viděl!

    Btw, zajímalo by mě jak se v takových případech řeší verzování – tedy, když si s deseti miliony uživatelů vzpomenu, že by měl mít uživatel navíc třeba profilové foto, a jen foreach user { get, unserialize, pridej_foto, serialize, put } trvá třeba týden.

    Asi bych přidal každé entitě typ a verzi, a pro každý typ a verzi entity bych měl připravenou funkci, která by se zavolala při prvním přístupu k entitě a upgradovala by jí na aktuální verzi:


    for (i=entity.version; i < actual_versions[entity.type]; i++) {

      upgrade_function_name = "upgrade_{entity.type}_{entity_version}";

      if (function_exists(upgrade_function_name)) {

        entity = call(upgrade_function_name, entity);

      }

    }

    Co na to čtenáři?

    PS: vkládání kódu sucks – odsazoval jsem pomocí nbsp;, uvnitř tagu code jsem musel odřádkovávat s BR, a menšítko jsem musel zapsat jako entitu… to se dá snad i v Drupalu naklikat za 20 minut víc user friendly :((. A když už jsme u toho, kód by měl být o hodně menším písmem…

    1. keff

      Re: Díky

      … a teď mě napadá že to celé musí být v transakci (jinak se nám může entita upgradovat vícekrát – a pravděpodobně bude, stačí když netrpělivý uživatel refreshne stránku dřív než doupgradujeme, nebo se třeba zavolá API call). Takže buď potřebujeme aby naše hrdá NoUglySQL pokorně vzala z sql transakce (begin; get; upgrade; put; commit;), nebo musíme použít princip ala JavaSpaces, kde get objekt z db vyndavá, a i po čtení ho musíme zase putem vrátit zpět (a doufat že mezitím nespadneme :)).

    2. Jakub Vrána

      Re: Verzování

      Vtip je v tom, že se záznamy vůbec modifikovat nemusí. Z databáze se prostě načte beztypový slovník. Když s tímto slovníkem potom pracuji, tak jen musím počítat s tím, že tam některé klíče prostě nebudou.

      1. keff

        Re: Verzování

        V tom případě bych nechtěl být ten, kdo píše logiku aplikace – vážně myslíte, že je lepší, aby v sobě měla každá funkce pracující s entitami (třeba i 3 roky starými) víc ifů a switchů, než vlastní byznys logiky?

        Ne že bych chtěl vypadat jako zapšklý strongly typed konzervativec, ale mě přijde lepší vědět že entita user má ta a ta pole, než psát funkci která bude rozumně fungovat s jakoukoliv verzí uživatele která se používala během celého života aplikace. A tohle není žádný umělý problém, nastává všade kde se neupravují data společně s programem (a zrovna ho náhodou taky řeším, proto mě zajímají názory ostatních :)).

        1. Jakub Vrána

          Re: Verzování

          Ale ona to vůbec nemusí řešit každá funkce. Stačí, když to vyřeší nějaký centrální prvek (zde asi přímo datastore při získávání dat).

        2. Ped

          Re: Verzování

          Ja bych rekl ze vetsina funkci ktere pracuji s entitou pracuji prave s konkretnim atributem (dvema-trema), takze mnozstvi ifu nebude az tak velke, mozna 1–2 na zacatku funkce, jestli se da vubec aplikovat na danou entitu.

          T.j. rozsirovani entit podle mne nezpusobi v zdrojaku takovy chaos (vetsina puvodnich funkci nove atributy do ted nepotrebovala, tak je nejspis nebude potrebovat ani po jejich pridani) jako treba nejaka zmena atributu aby v novejsich entitach obsahovali trochu jine data a pod.

          A mam takovy pocit ze se porad bavime na urovni „modelu“, t.j. casti ktera se da docela dobre pokryt unit testy a refactoring/roz­sireni je pak relativne stejne drahe po celou dobu vyvoje bez ohledu na aktualni slozitost entity. Proste to tak od oka napisete po novem, pustite testy a zjistite jestli jste se trefili nebo tomu neco chybi. Vetsinou pak failed testy napovi co jste od oka nedomyslel, je to vlastne takova vedomostni databaze ktere se muzete velmi rychle ptat na „jednoduche“ programatorske problemy typu „kolik funkci se mi rozbije kdyz tohle v entite zmenim“ a pod… (ktere vypadaji jednoduse, ale pri slozitejsi entite a vetsim mnozstvi funkci uz jejich reseni v hlave trva nejakou dobu .. rozhodne vic nez natukani nejakeho prototypu zmeny a pusteni testu)

        3. Inkvizitor

          Re: Verzování

          No tak v některých jazycích se to dá vyřešit elegantněji. Např. v Pythonu se na slovníku použije operace get(), která má implicitně pro neexistující klíče hodnotu None a případně se tam dá nějaká hodnota explicitní (škoda, že Python v takových případech neumožňuje jednoduše líné vyhodnocování funkcí jako některé funkcionální jazyky – Haskell, OCaml apod. – to by byla teprve paráda).

          Víc by mě trápila jiná věc – pokud ten model není triviální, dojde člověk nakonec často k tomu, že si začne vytvářet vlastní mechanismus indexů apod., zkrátka se selektováním řádků (v horším případě i s joiny) mu databáze nebude umět pomoci. To se časem může strašlivě vymstit a trpí výkon celé aplikace. Časem zjistíš, že Ti zabere spoustu času optimalizace a simulace relační databáze nad NoSQL. Samozřejmě, pokud člověk ví, kde takovou jednoduchou databázi použít, může se to hodit. Obecně jsem ale spíš pro opatrnost.

    3. Michal Krause

      Re: Díky

      Pokud jde o vkládání kódu, stačí jej uzavřít do

      <pre><code>kód</co­de></pre>

      případně použít Texy zápis:

      /—code
      kód

  2. Jakub Vrána

    Neblokující ALTER

    Což o to, řešení je to chytré a evidentně funkční. Ale přijde mi škoda, že kvůli jednomu problému (blokující ALTER) do značné míry rezignovali na schopnosti MySQL a emulují si je sami (místo indexů vytváří tabulky a místo změny struktury modifikují BLOB).

    Možná, že kdyby stejné úsilí napřeli do toho napsat neblokující ALTER (tedy patch pro MySQL a hlavně InnoDB), tak by výsledek byl stejný a mohli by z toho těžit všichni. Tedy i ti, kteří MySQL využívají jako relační databázi.

    1. aprilchild

      Re: Neblokující ALTER

      Napsat neblokujici ALTER pro velkou databazi je asi jako napsat novy databazovy stroj. To myslim jako odpoved staci. Do toho se nepousteli ani sakra chytri kluci z FF (jeden z nich, Paul Buchheit napsal GMail, to jen kdyby nejakeho stouru napadlo pochybovat, ze jsou chytrejsi nez on).

    2. Martin MalýAutor příspěvku

      Re: Neblokující ALTER

      V každé diskusi, kde se popisuje nějaké řešení, se vždy objeví alespoň jeden člověk, který napíše, že to měli (mohli) udělat úplně jinak, jednodušeji a smysluplněji… Dnes ses této role zhostil ty, gratuluji! :)
      Nemám důvod pochybovat, že by parta vývojářů z FriendFeedu nezvážila i tuto možnost. Nakonec ji pravděpodobně z důvodů, z nichž známe jen část, hodili do pytle s nápisem „… a další slepé cesty“. Nezdá se mi, že by dev crew z FF byla grupa matláků, která by to nezvládla, kdyby to viděla jako smysluplnou cestu; jako mnohem pravděpodobnější se mi jeví eventualita, že potřebovali vývojáře na vývoj služby FriendFeed a ne na přepisování a patchování DB enginu.
      Ano, degradovali MySQL na prosté úložiště blobů. Rezignovali na jeho RELAČNÍ DATABÁZOVÉ schopnosti a využili pouze ACID (a i to „napůl“). Učinili tak (jak píše v článku) po zralé úvaze, jejímž výsledkem bylo, že RELAČNÍ schopnosti nepotřebují (a stejně je nepoužívají).
      Ostatně, těch problémů bylo víc než blokující ALTER, a něco z toho tam i píše. Např. sharding databáze prakticky znemožnil JOIN (tedy základ RDB). Pro JOIN nad rozdělenou databází bys musel (tipuju, nezkoušel jsem a ani nechci) vytvořit cluster a řešit to nad ním – to jsou všechno věci, které velmi pravděpodobně v článku spadly do toho odstavce „tyto operace jsou tak náročné, že jsme se rozhodli opustit SQL“.

      1. Jan Kodera

        Re: Neblokující ALTER

        On ten ALTER má problém v tom, že MySQL jako řádkově orientovaná DB prostě trvá na tom, že každý sloupec musí být v řádku naznačen (buď NULL nebo nějaká default hodnota). A prolézt celý soubor chvilku trvá, zvlášť když tam jsou věci jako BLOB, či TEXT u kterých není jasné jak jsou dlouhé, takže se musí projít a pak se posunout. Práce by to byla strašlivá.

        Oni přece úplně nerezignovali na relační schopnosti. Oni je používají (viz index je v relaci s entitou apod.). Spíše se jedná o rezignaci na 3 normálovou formu. Data jsou denormalizována a tudíž není třeba tolik JOINů (vlastně žádné). Jak se píše v článku, tento přístup pak přenáší část práce na aplikaci (poslední filtraci dat).

      2. Lukas

        Re: Neblokující ALTER
        V každé diskusi, kde se popisuje nějaké řešení, se vždy objeví alespoň jeden člověk, který napíše, že to měli (mohli) udělat úplně jinak, jednodušeji a smysluplněji…

        A to je spatne? Myslim ze ne, nekdy se stane, ze takovy komentar ma vetsi hodnotu nez cely clanek.

        1. Martin MalýAutor příspěvku

          Re: Neblokující ALTER

          Někdy se to stane, ano… Většinou ale ne, většinou to je ukázkový „pobitvěgenerál“, navíc z úplně jiné války! Hodnotu větší než celý článek to může mít třeba v případě, kdy komentátor zná poměrně přesně situaci, v níž se dotyční rozhodli, faktory s nimiž počítali, a dokáže relevantně vyargumentovat, že se rozhodli špatně, popř. uvést faktor, který by dramaticky změnil celé rozhodování. :)

  3. aprilchild

    Klasicky zdroj pro NoSQL

    pro zajemce, temer klasikou se stal post R. Jonese

    „Anti-RDBMS: A list of distributed key-value stores“. Jedna se o starsi text, s nejnovejsi diskuzi. Neni to sice uplny seznam (kdo ho ma..), ale jako uvod do problematiky a vlastniho studia se hodi.

    http://www.metabrew.com/…alue-stores/

  4. Martin Soušek

    takže v zásadě nic nového

    Zdá se mi, že znovuobjevili dávno známou věc.

    Stačí si přečíst pár patentů Google, vyzkoušet AppEngine a zjistíte, že tohle bylo dávno vynalezeno. Ani není potřeba ta MySQL.

    S každým to bohužel zamává, protože tyto škálovatelné přístupy staví na hlavu všechno, co jsme se doposud učili a považovali za jediné možné.

    1. Palo

      Re: takže v zásadě nic nového

      Alebo si aj precitajte o problemoch z AppEngine a ake jednoduche tieto technologie su. Postavit na tom mail system ktory obsahuje tak 4 polozky ale hlavne to musi byt rychle je uplne nieco ine ako vytvorit ERP system.
      Ked to potrebujete aj tak tam musite strcit nejaku vrstvu ktora vytvori vyssi interface. Takze v podstate nic nebrani tomu vytvorit rovnaku strukturu pod standardnym SQL systemom. Je to iba otazka vytvorenia noveho DB systemu ktory by bol od zaciatku navrhnuty ako distribuovany a skalovatelny. Tieto vlastnosti sa do existujucich SQL databaz pridavali az dodatocne.

    2. Martin MalýAutor příspěvku

      Re: takže v zásadě nic nového

      Oni nikde netvrdí, že objevili něco extra nového. Přečtěte si to pozorněji: Oni dospěli k nějakému řešení, k nějakému mezikroku mezi SQL a NoSQL, píše tam proč k němu dospěli, a i to „proč nad MySQL“ je tam napsané (mají MySQL, znají MySQL, umí s MySQL…)

  5. X

    NoSQL?

    Budu si to muset přečíst ještě jednou. Napoprvé to na mě působí jenom jako optimalizovaná db architektura a takto si nepředstavuji NoS­QL.

    Trochu se mi nezdá, když mluvíte o tabulce s ~25 (250) miliony záznamy a reindexace trvá několik hodin. Nějaké informace o datové větě, či velikosti tabulky v bytech by nebyly?

    1. PM

      Re: NoSQL?

      „tabulce s ~25 (250) miliony záznamy a reindexace trvá několik hodin“ – to není vůbec nereálné.

      1. Martin MalýAutor příspěvku

        Re: NoSQL?

        Na serveru jsem měl kdysi tabulku s ~1M záznamů (metainformace ke komentářům ke všem článkům všech blogů). Věta měla pevnou délku (žádné varchary, jen char a int). Když jsem chtěl přidat index na jeden sloupec, zkusil jsem to za běžného provozu – během pěti minut server ležel a watchdog ho restartoval. Takže jsem v noci odpojil HTTP server a udělal index. Bez zátěže to trvalo krásných 15 minut. Takže reindexace v řádu několika hodin mě vůbec nepřekvapuje.

              1. Martin MalýAutor příspěvku

                Re: NoSQL?

                Pak tedy dobrá, už jsem se lekl. :)
                Byla to MyISAM (z historických důvodů) a řetězcové záznamy byly v plain ASCII – šlo, jak píšu, o metadata, např. o doménu, z níž byl komentář odeslán (šla-li zjistit z reverzní DNS) nebo o různé příznaky, kde je úplně jedno, jestli to je tinyint nebo char(2) (třeba), jen ten char se člověku líp čte. :)

                1. fos4

                  Re: NoSQL?

                  Treba by enum vysel lepe nez tinyint a char. Nevim jak je to s rychlosti budovani indexu u intu a enumu ale tusim ze char a varchar budou pomalejsi.

                  1. Martin MalýAutor příspěvku

                    Re: NoSQL?

                    Nebudoval jsem index nad enumem ani char(něco-málo), budoval jsem nad větším char() – konkrétně ty domény.

  6. Ivan

    Hracka

    A neni hlavne hrani? Ty kluci do toho museli investovat dost casu(tzn. i penez).
    Kdyby si za ty penize poridili nejaky rozumny zelezo s vice jak 150GB RAM, tak mohli cely MySQL nahradit necim co ma vsechna data v RAMce a jednou za cas je odlije na disk. Oni vlastne zadnou DB nepotrebuji jedna giganticka hash tabulka by jim stacila na vsechno.

  7. Jiří Knesl

    Bulvární titulek

    Arthure, tohle: „Vývojáři začínají často narážet na omezení relačních databází, jejichž návrh je sice časem ověřený, ale přece jen poněkud staršího data.“ je pokud o zvýšení čtenosti, nebo je to myšlené vážně?

    Já jen že (až na možnost uložení libovolné struktury) jsou relační databáze povětšinou podstatně méně omezené, než key-value storage. Srovnávat databázi a storage je jak srovnávat náklaďák a porsche – náklaďák se hodí na 100* víc věcí, porsche jen rychle jezdí.

    <flamebait>

    Mě osobně (ač je mi nosql sympatické) přijde, že se z nosql dělá posvátná kráva neskutečných rozměrů, občas slyším výkřiky (ne od tebe), že sql je překonané a že budoucnost je v schema-less storages. Leda prd, relační databáze jsou 1. podstatně silnější (kolik jazyků podporuje postgre? 7? 8? a kolik k-v storages? jen javascript), 2. lépe podporované (skutečnými firmami, ne skupinkami geeků po 3 lidech), 3. vhodnější na 95 % aplikací (tedy všude tam, kde není nutné pracovat s terabajtovými objemy dat), 4. pokryté mnohem lépe vývojářskými nástroji, 5. dostupné na levných hostinzích, 6. něco málo v nich napíše i ta největší lama, co si myslí, že databáze = relační.

    Těším se, až tenhle buzz skončí, těch 5 %, co schema-less užije, si je bude používat, dalších 95 % bude dál používat sql a svět bude spokojený a natěšený na další hurráábuzz (třeba nohtml – to bych se možná i zapojil).

    </flamebait>

    1. krteQ

      Re: Bulvární titulek

      NoSQL neni pro kazdeho. Je to pro firmy, ktere maji mysql na 100+ serverech a potrebuji snizit naklady na HW a administraci.

      Pokud aplikace nepotrebuje nutne ACID operace a nepotrebuje relacni DB, da se takto usetrit i 75% nakladu. Musite byt ale dostatecne velka firma, ktere se to vyplati, a ktera ma na to lidi (admini, programatori).

      Pokud se bavime o provozu na nejakej sdilenem hostingu, tady je NoSQL IMHO jen nepotrebny offtopic a kazdej se o tom bavi jen proto, ze je to cool :)

        1. Jiří Knesl

          Re: Bulvární titulek

          Třeba tak, že uchovává relační data a jiný formát databáze/storage (stromová, k-v) je jen ohýbání. Těžko to můžu podpořit nějakou statistikou, ale troufnu si říct, že drtivá většina aplikací, které kdy vznikly, vznikají a v budoucnu vzniknou, budou uchovávat právě relační data.

          Používat na tato data cokoliv jiného je drbání levou nohou za pravým uchem. Jde to, ale…

          1. Martin MalýAutor příspěvku

            Re: Bulvární titulek

            Jiří, stejně tak je křížovým drbáním napasovávat veškerá aplikační data na relační model. Jen nám to tak nepřipadá, protože to děláme automaticky a podvědomě. Troufnu si říct se stejnou sebedůvěrou jako ty, že většina webových aplikací, které kdy běžely nad *SQL, uchovávají relační data jen proto, že je tak někdo navrhl, a navrhl je tak proto, že měl k dispozici právě jen *SQL stroj.

            1. Jiří Knesl

              Re: Bulvární titulek

              Martine, já napasovávám relační model na relační data.

              Když dostanu uložit stromovou strukturu a mám jen sql databázi, taky u toho nadávám jak čert.

              Není jediný důvod, proč ukládat relační data jinak než v relační databázi (pokud těch dat nemám terabajt). Relačních dat je většina.

              1. Martin MalýAutor příspěvku

                Re: Bulvární titulek

                „Relačních dat je většina.“ – dokaž! Tedy lépe řečeno – dokaž, že „relačnost“ je jejich přirozená vlastnost!

                1. Palo

                  Re: Bulvární titulek

                  Velmi jednoducho. Analyza sa totiz robi tak aby z toho nakoniec relacny model vypadol ;-).

                  1. Martin MalýAutor příspěvku

                    Re: Bulvární titulek

                    Asi tak nějak. :)

                    Jinak aby nedošlo k omylu – s tvrzením „není důvod ukládat relační data jinak než do relační databáze“ plně souhlasím, jen se mi zdá, že argumentace se točí v kruhu: Data jsou relační proto, že je někdo jako relační popsal, a popsal je tak proto, že je bude ukládat do relační databáze!

                    1. Palo

                      Re: Bulvární titulek

                      Ale zas uvadzane riesenie je scestne lebo tiez vyuziva relacnu databazu. A to vsetko iba preto ze operacia pridania stlpcia a pridania indexu dlho trva? Tak to sorry, to nie je chyba relacneho modelu.
                      Ak raz niekto vytvori databazu kde pridanie stlpcia pripadne vytvorenie indexu pojde rychlo tak si mozu trieskat hlavu o mur.

                      1. Martin MalýAutor příspěvku

                        Re: Bulvární titulek

                        Četl jste nepozorně:

                        „Což nás v důsledku nutilo vyhýbat se přidávání takových funkcí, které by vyžadovaly změnu struktury nebo indexů. A protože se od doby, co jsme databázi rozdělili, staly „relační“ funkce jako třeba JOIN naprosto nepoužitelné, rozhodli jsme se porozhlédnout mimo svět relačních databází.“

                        „MySQL funguje. Nepoškozuje data. Replikace funguje. Známe její omezení. Máme rádi MySQL jako úložiště dat, ne kvůli tomu, že je to relační databáze.“

                        1. Palo

                          Re: Bulvární titulek

                          Ale opat to su technicke problemy nie chyba relacneho modelu. My robime aj s vacsimi tabulkami ako sa tu popisuje. Oracle, partitioning. Databazu sme delili ale tak aby to malo logicky zmysel. Takze udaje ktore patria spolu su spolu.
                          Kompletne udaje o zamestnancoch mozete mat v jedenej databaze a relaciu k nim v inej pripadne dolezite udaje vytiahnete koli JOINom aj do druhej databazy.
                          Uzavierky aj tak musia bezat offline. Fakt si myslim ze toto NoSql nema ziadny zmysel.
                          Existuje na to cely odbor ktory sa tym zaobera ETL.
                          http://en.wikipedia.org/…nsform,_load

                          Pripadne duplikaciu udajov vyriesite v aplikacnej vrstve (ha-jdbc, sequoia). V kazdom pripade mi pride jednoduchsie ako toto riesenie ktore urobili oni.

                    2. Petr

                      Re: Bulvární titulek

                      Důvodem pro relační model není ukládání dat, ale způsob práce s daty.

                      Problémem je, že hodně lidí chápe relační databáze (doslova pouze) jako uložiště a pak si z nich zákonitě dělají druhý souborový systém.

                  2. František Kučera

                    Co se učí a co dělá.

                    No jo, jenže tohle se ve škole neučí – tam tě učí, že máš začít datovou analýzu nezávisle, bez nějakých předsudků, zda to bude relační, objektová nebo hierarchická či jiná databáze. V druhém stupni, na základě předchozího, rozhodneš, který z těch modelů to bude, který vyhovuje nejlíp. A až ve třetím kroku vybereš konkrétní implementaci SŘBD*. Jenže to by lidi tyhle poučky nesměli považovat za akademické kecy a nesměli by hned po první schůzce začít črtat tabulky (nejlíp rovnou jako CREATE TABLE v konkrétním dialektu).

                    (na druhou stranu stejně by člověk ve většině případů vybral zase tu relační…)

                    *) třeba ten Oracle „za který ještě nikoho nevyhodili“ nebo MySQL, „protože s ní děláme odjakživa“, nebo PostgreSQL, protože je to nejlepší z open sourcu.

                    1. Martin MalýAutor příspěvku

                      Re: Co se učí a co dělá.

                      Vybral by „tu relační“, protože je na ni zvyklý. Dost možná by už při analýze nepřemýšlel „jaká databáze to bude“, ale „jak to bude v relační databázi“. Protože relační databáze máme, známe, jsme na ně zvyklí, a zvyk je minimálně železná košile, když ne rovnou posvátná kráva. :)

                    2. backup

                      Re: Co se učí a co dělá.

                      … tam tě učí, že máš začít datovou analýzu nezávisle, bez nějakých předsudků, zda to bude relační, objektová nebo hierarchická či jiná databáze. V druhém stupni, na základě předchozího, rozhodneš, který z těch modelů to bude, který vyhovuje nejlíp …

                      to je jeden z nejvetsich problemu informacni technologie, totiz, ze se na svet diva skrze projekcni bryle. V drivejsich odvetvich to take bylo tak, i auto staveli panove Benz a jini pred sto lety na zakazku a staveli se k tomu jako k projektu. Toto mysleni pretrvava v IT dodnes a proto se muze SQL stale drzet. V projektu se totiz nevidi, kde se utopi ty naklady, projekty jsou z principu prodelecne at uz je to web nebo elektrarna. Vzdycka to stoji 2 x tolik a trva to 2 tak dlouho. Z techto duvodu jeste nikomu nedoslo, ze SQL je jednim z tech velkych problemu

                      Polehoucku se ale objevuji prvni vlastovky (pan Maly) , kteri si dovoli prohlasovat. ze SQL neni posvatna krava. Brzy se jiste dovime i proc.

              2. Jiří Kosek

                Re: Bulvární titulek

                Nene, relačních dat je menšina, podle různých studií tak max 5%. Většina dat je nestrukturovaná nebo semi-strukturovaná. Relační model realitu dost ohýbá, pro většinu aplikací je např. mnohem vhodnější datový model XML.

                1. Palo

                  Re: Bulvární titulek

                  Toto je bludne tvrdenie. Kde je ta statistika? Vacsina veci ma totiz vztahy typu N:M co musite aj v XML vyriesit iba smernikom cez identifikator – relacia.

                  Clovek MA napriklad pecen co ide v XML pekne ale keby som robil SW pre nemocnicu tak by som kazdy organ radsej drzal vo vztahu k cloveku cez relaciu lebo ked ju niekomu preoperuju tak XML asi bude nevhodne.

                  1. Martin MalýAutor příspěvku

                    Re: Bulvární titulek

                    „Vacsina veci ma totiz vztahy typu N:M“ – protože je ukládáte do relačních databází, tak jim tyto vztahy přisuzujete (musíte, jinak byste je tam neuložil). Mimochodem, kolik pacientů bude podstupovat transplantaci jater (pečene, že? Ledviny jsou jinak…), aby to OSPRAVEDLNILO napasování do relačního modelu „člověk – orgány“? A které orgány budete takhle oddělovat do různých tabulek? Všechny? Proč? Je prohazování orgánů mezi pacientama tak častá operace, aby ospravedlnila rozbití logického celku (člověk) do relačního modelu?
                    I kdyby šlo o transplantační oddělení nemocnice, tak není nutné ani lepší použít relační model. Mohu klidně (a logičtěji) použít entitu „člověk“, které dám atribut „darce_jater“ – a v něm bude druhá entita „člověk“. Mně to připadá logičtější než rozštípnout člověka na „schránku“ a „orgány“.
                    Pokud ale budu v situaci, že v zadání bude „Běh na MS SQL serveru“, tak je logické, že z toho ty relační vztahy udělám. Ale to není argument, to je pouze setrvačnost.

                    1. Palo

                      Re: Bulvární titulek

                      A teraz pride zlaty klinec – reporting. To ako budete pisat tie dotazy, filtre agregacie (pouzitim SQL?)? K tomu vasmu systemu neexistuje aparat ktory z relacnym model suvisi. Robit to systemom citania filov z blobov mi opat pride ovela nepohodlnejsie, pomalsie, neflexibilnejsie, narocnejsie.
                      Boli tu uz objektove databazy, XML databazy, … . Ja osobne robim z Javou takze napriklad objektove databazy su pre mna vhodnejsie riesenie. Nakoniec ale narazite na problemy a zistite ze SQL je zakladom vsetkych na ktorych mozete stavat. Urobit XML databazu nad SQL ide. Tak isto ako ide vytvorit NoSQL databazu nad SQL :-D.

                      1. Martin MalýAutor příspěvku

                        Re: Bulvární titulek

                        „Robit to systemom citania filov z blobov mi opat pride ovela nepohodlnejsie, pomalsie, neflexibilnejsie, narocnejsie.“ – problém je v tom, že „vám připadá“, a to je taky celé jádro sporu. Jiní nedali na svá „připadání“, zkusili to – a vyšlo jim něco jiného, tak se o poznatky podělili.

                        A o tom (a o ničem jiném) je celý článek. Můžete ho číst jako zajímavou zkušenost, která vás třeba přiměje zkusit své „připadání“, „dojmy“, „dobré důvody“ a „jednoznačné pravdy“ oprášit a zrevidovat, nebo ho můžete vzít jako útok na posvátnou krávu, kterou je potřeba bránit. To už nechávám na vás.

                  2. Jiří Kosek

                    Re: Bulvární titulek

                    Ne není, jen naráží na mentální bariéru mozků, které jsou posledních třicet let trénovány na relační model dat. Pokud jste vystudoval nějakou IT školu, jste analytik nebo děláte s databázemi, máte zkrátka praxí zkreslený pohled na věc. Neříkám, že to je dobře nebo špatně, ale je to tak.

                    Když se řekne faktura, představí si člověk postižený databázemi několik tabulek – pro hlavičku, pro odběratele, dodovatele, položky faktury, … a jak je to pěkně provázané vztahy.

                    Normální člověk si při vyslovení slova faktura představí takový ten papír – zkrátka fakturu. V případě použití datového modelu XML stačí okolo informací na „papírové faktuře“ doplnit elementy a máte vystaráno. XML nemá problémy s opakováním údajů, s hierarchickou strukturou atd. XML reprezentace faktury je mnohem bližší skutečné faktuře než její relační datový model.

                    Konec konců podívejte se na to, co většinu času dělá aplikace pro vystavování faktur, které se ukládají do relačního datového modelu. Asi zjistíte, že to je mapování mezi tím, jak faktura vypadá pro potřeby vstupního formuláře nebo naopak výstupní sestavy a tím, jak to rozkouskovat a zase poskládat z několika tabulek.

                    Statistiku stačí vygooglit, je to všeobecně uznávaný fakt, jen se liší odhady mezi 80–95% (pro nestrukturovaná data), např.:

                    http://clarabridge.com/default.aspx?…

                    1. Jakub Vrána

                      Re: Bulvární titulek

                      Co když zjistím, že u jedné firmy mám překlep v adrese a potřebuji ho opravit u všech faktur? Nebo že název zboží na půlce faktur neobsahoval důležitou informaci, kterou chci doplnit?

                      Jednou z hlavních výhod relačního návrhu (v 3NF) je to, že jsou všechna data uložena právě na jednom místě (kromě primárních klíčů, které by měly být neměnné).

                      Pokud bych naznačený scénář chtěl realizovat s XML dokumenty, tak si tam ty tabulky a relace taky musím navrhnout a do XML je schovat.

                      1. Jiří Kosek

                        Re: Bulvární titulek

                        Tak zrovna 3NF je pro účetní doklady naprosto nevhodná, protože ty není možné zpětně v čase modifikovat (pomíjím tedy možnost, že by se do tabulek přidala ještě dimenze času, která by říkala v jakém okamžiku byla daná adresa platná, což by relační datový model a dotazy ještě pěkně nafouklo).

                        Samozřejmě, pokud je to z povahy problému potřeba, můžeš něco jako relace (odkazy na jiné XML nebo jeho části) používat. Výhoda datového modelu XML je v tom, že když se to hodí, nemusíš spolu související data zbytečně rozbíjet do několika tabulek a jde s nimi pracovat najednou jako s jedním celkem.

                        1. František Kučera

                          Adresy ve fakturách

                          „Tak zrovna 3NF je pro účetní doklady naprosto nevhodná, protože ty není možné zpětně v čase modifikovat“

                          Mně to ale nepřijde jako něco v rozporu s normální formou. Údaj (adresa) na faktuře k nějakému datu je prostě jiný údaj než adresa v aktuálním adresáři firem. Řešit to odkazem, cizím klíčem, IMHO není lpění na normální formě ale obyčejná hloupost (odkazujeme se někam, kam bychom neměli).

                          „možnost, že by se do tabulek přidala ještě dimenze času, která by říkala v jakém okamžiku byla daná adresa platná“
                          Je to jedno z řešení. Druhou možností je mít jednu adresu pro každou fakturu – ani tak to nemusí být denormalizace dat – stačí se na to dívat tak, že adresa k 2010–01–07 11:28 je svébytný údaj a je to něco jiného než adresa (k jiné faktuře) k okamžiku 2010–01–07 11:35. Je to něco jako naměřené hodnoty třeba z teploměru – jednou jsme naměřili 10°C, za hodinu naměříme zase 10°C, ale taky to nebudeme řešit cizím klíčem na nějaký jeden záznam…

                    2. František Kučera

                      Faktury

                      „XML reprezentace faktury je mnohem bližší skutečné faktuře než její relační datový model.“

                      A není ta faktura (jakožto kus papíru) také jen modelem reality? I když je to model nepočítačový – ale zachycuje nějaké vztahy (někdo někomu něco prodal – kolik, čeho, kdy…).

                      Ale je fakt, že třeba účetnictví založené nad eXistem by mohlo být zajímavé a asi by to fungovalo (aspoň do nějakého objemu dat) tisk a různé exporty by byly efektivnější a přímočařejší, zatímco sčítání a další agregace trochu složitější (než třeba sum() v relační databázi).

                    3. Karel Minařík

                      Re: Bulvární titulek

                      Díky. Jak velmi přesně píšete, to „mapování mezi tím, jak faktura vypadá pro potřeby vstupního formuláře … a tím, jak to rozkouskovat a zase poskládat z několika tabulek“ je právě to, co je na současném stavu tak zoufalé. A to přestože to mapování děláme přes nějakou abstraktní vrstvu ORM. (Mimochodem, bylo by príma, kdyby sem napsal někdo, kdo takovou abstraktní vrstvu píše, abychom tady viděli někoho, kdo má _skutečně_ důvod být na dominanci *SQL hodně, hodně naštvaný :)

                      Přesně tenhle příklad s fakturou funguje jako hlavní use-case pro úvod do CouchDB (a tím pádem zprostředkovaně pro MongoDB, etc etc): http://books.couchdb.org/…/why-couchdb#…, citace:

                      > An invoice contains all the pertinent information about a single transaction; the seller, the buyer, the date, and a list of the items or services sold. As shown in Figure 1–1, there’s no abstract reference on this piece of paper that points to some other piece of paper with the seller’s name and address. [zvýr. KM]

                      1. okbob

                        Re: Bulvární titulek

                        Já mám spíš problém, že by měl být někdo hodně naštvaný spíš na filozofii OOP, které chybí background pro hromadné operace. Což zase umí databáze. Tady jde o dva rozdílné světy, a z toho vychází všechny kolize. Na jednu stranu by programátoři rádi používali OOP, na stranu druhou díky OOP nelze řešit hromadné operace. Databáze jako CouchDB ten problém do jisté míry eliminují – v tom se podobají MySQL – jednoduché operace umí velice rychle.

                        Problémem není dominance SQL. Problémem je nepokrytí určité oblasti filozofií OOP. Případně rozpor mezi dvěma neslučitelnými systémy – OOP (umí pohodlně pracovat s jednotlivými objekty), RDBMS (umí efektivně pracovat (dynamicky) s velkými množinami dat).

                        1. okbob

                          Re: Bulvární titulek

                          sorry – nepřečetl jsem si to po sobe. Začátek „Někdo by měl být spíš naštvaný na OOP“

                          p.s. otázky, které tu řešíme, bychom pravděpodobně neřešili, kdyby byly k dispozici OOP databáze. Což je asi ta šedá oblast, která se porůznu pokrývá ORM, NoSQL databázemi, XML databázemi.

                          1. Almad

                            Re: Bulvární titulek

                            Ale objektové databáze k dispozici jsou – ZoDB, GemStone.

                            Jenom nemají ty výkonnostní, případně finanční charakteristiky. A že objektové databáze spasí svět, o tom se mluví minimálně tak dlouho, jako že svět bude spasen pomocí XML.

                      2. František Kučera

                        Pokrok

                        Někdy přemýšlím nad přínosem zavádění IS/IT pro život :-) Potenciál pro zlepšení je v přestavbě procesů (která je umožněná novými technologiemi, které dřív nebyly), ne v tom, že vezmeme ty staré procesy a elektronizujeme je (a tak zafixujeme). Tím, že něco „dáme do počítače“ to nebude automaticky fungovat líp. Faktura jakožto dokument odráží prostředky dostupné ve své době – tužka, papír, psací stroj. Odkazovat se v argumentaci na vlastnosti „kusu papíru“ je směšné. Ten papír není nic primárního, je to jen lidský konstrukt, model snažící se zachytit nějakou skutečnost (ta je primární). Pokud chceme dělat věci líp (něž účetní za první republiky) musíme je dělat jinak…

                        1. Palo

                          Re: Pokrok

                          > Pokud chceme dělat věci líp … musíme je dělat jinak
                          Este ste zabudli ze ked ich budete robit inak mozete ich robit aj horsie. Na to aby ste robili veci lepsie musite poznat ich historiu a dokonca aj s celym okolim ktore na to vplyvalo a snazit sa to napasovat na sucasne podmienky lepsie. Vsetko sa da robit aj lepsie pretoze okolie sa meni ale u historicky preverenych veci je velmi pravdepodobne ze ak ich budete robit inak budete ich robit horsie.
                          Zoberte si armadu. Hodnosti, utvary, postupy, riadenie. Mozete to robit inac ale s vysokou pravdepodobnostou iba horsie a ak tak iba male zmeny, ziadne zmeny filozofie armady su nepripustne.
                          Tak to mate aj s relacnymi databazami. Relacna teoria vznikla hrozne davno a je casom overena. Mame tu rozne implementacie a moznosti ako do nej napasovat XML, objektove a vselijake ine udaje (dokonca aj NoSQL :-D). Zasadna zmena je to iste chciet menit podstatu pocitaca, CPU, MEM. Ano mame pokusy s kvantovymi pocitacmi a podobne ale to je dnes uplne mimo misu. Tak ako chciet robit veci INAC.

                          1. František Kučera

                            Re: Pokrok

                            1) Nepochopená implikace? „líp → jinak“ přece neznamená, že „jinak → líp“.

                            2) Ne, já nepatřím k fanatickým odpůrcům relačních databází (spíš naopak, když se nedržím na uzdě :-). Tím dělat věci jinak jsem právě myslel oprostit se od toho, že faktura je kus papíru, dokument, celek. Protože ta faktura je jen model reality (sekundární) a když budeme hledat to primární, zjistíme, že tu jsou nějaké entity a vazby (kdo, komu, co, za kolik). XML mám rád, je to skvělá technologie se spoustou využití, ale zrovna pro to účetnictví mi přijde vhodné jen jako formát pro výměnu dat, nikoli pro jejich ukládání – na to se víc hodí ten relační model.

                      3. Lukáš Konarovský

                        Re: Bulvární titulek

                        Jako spoluautor webové aplikace pro správu faktur Fakturoid, který použil PostgreSQL, si říkám: škoda, že tehdy neexistoval MongoMapper :)

                        Spousta věcí by se řešila elegantněji, řádky by se vložily přímo do faktury, údaje o odběrateli a dodavateli taktéž (hezky jako zanořené objekty, ne placatě, jako to je teď).

                        Přepisovat to teď není zrovna dobrý nápad, ale v příští aplikaci bych data velmi rád ukládal do něčeho, kde se nemusí neustále migrovat schéma, kde nejsou potřeba podivuhodné praktiky pro rozdrobení dat do tabulek a jejich zpětné scucávání zpátky :)

                        1. František Kučera

                          Fakturoid

                          Předně bych rád pochválil Fakturoid :-) Když jsem na něj koukal posledně, tak byl jen blog, teď jsem konečně viděl, jak vypadá ta aplikace – pěkné, jak vzhledově, tak ten nápad*.

                          Teď k těm relacím – „Fakturoid je aplikace pro tisk a správu faktur“ – vytvářet a archivovat nějaké dokumenty je diametrálně odlišná aplikace než účetnictví. Když jsem tu psal, že faktura představuje nějaké entity, vztahy, relace… tak to bylo v souvislosti s účetnictvím – to se podle mého bez relační databáze napsat nedá a pokud to někdo dokáže, tak je to frajer (nebo blázen) a má můj obdiv :-)

                          Aplikaci typu Fakturoidu bych asi psal nad XML databází. Tedy pokud by aplikace neměla ambice vyvinout se časem v plnohodnotné účetnictví. Stejně tak by tahle aplikace fungovala** nad NoSQL databází a jak je vidět, funguje i nad SQL – je to prostě v první řadě o tom nápadu (ten je nejdůležitější) a až teprve potom o technologiích.

                          *) jen mám trochu pochybnosti ohledně toho, že bych měl svoje data o účetní poskytovat někomu cizímu, ale jistě se najdou lidi, kterým tohle nevadí.

                          **) fungovala, ale psát bych ji nechtěl.

                    4. Palo

                      Re: Bulvární titulek

                      Sami si odporujete. Aj XML su strukturovane data. A aj XML sa da velmi pohodlne ukladat do relacnej SQL databazy. Vy iba nechcete vidiet to ze strukturovane data nie su iba relacne data a to XML vas hrozne pletie. Takze relacny strukturovany model vasho struktovaneho XML je uplne presne realizovany a XSD nie je nic ine ako inac zapisane DDL pre databazu.

                  3. František Kučera

                    Re: Bulvární titulek

                    „Toto je bludne tvrdenie. Kde je ta statistika? Vacsina veci ma totiz vztahy typu N:M“

                    Jenže ta statistika se netýká teoretické podstaty těch (čistých) dat, ale praktické situace – a ty čísla přibližně pravdivá jsou, firmy mají opravdu většinu dat (měřeno objemem) jako nestrukturovaný hnůj a jen zlomek (datovým objemem, ale asi ne důležitostí) strukturovaně. Prostě je to rozpor v tom, jak by to mělo být a jak to je – a je to tak, že opravdu těch nestrukturovaných dat je víc (byť by měla/mohla být strukturovaná).

                2. František Kučera

                  Re: Bulvární titulek

                  Jenže to podle mého nebude podstatou těch dat, ale spíš tím, že se lidi ve firmách chovají k počítači jako dříve k psacímu stroji – akorát to místo do šanonů strkají do adresářů a pak končí na terabajtových diskových polích.

                  Mně zase přijde, že realitu ohýbá XML svojí jednodimenzio­nalizou, ale to ne vždy vadí. Každopádně ale lepší XML (se svými schématy, validacemi, transformacemi…), než k-v noSQL (ne že by nemělo využití, ale IMHO je to okrajová záležitost).

                3. HolyHop

                  Re: Bulvární titulek

                  Mr. I love XML se ozval ;) Ale notak pánové, všichni jsme tu tak trochu strůjci svojeho štěstí co ? :)

                4. Palo

                  Re: Bulvární titulek

                  A to ako kam tie XML data chcete strkat. Na filesytem? Alebo ako BLOBY do databazy? A potom ked vam niekto povie urob report na vsetky faktury ktore nie su plne uhradene usporiadane od najvacsej dlznej sumy tak si to zoberiete ako projekt na niekolko dni a jeho vykonanie bude trvat 2 hodinky. Namiesto toho aby ste usmolil nejaky SQL command pripadne pomocou drag&drop reporting toolu si to pomaly sam urobi uz aj financny riaditel.

                  Ved vy ludia uplne stracate sudnost. Viete co je hlavny dovod pouzivania normalnych foriem a relacnych databaz? Vsak to nerobime preto ze sa nam to paci. Taky tu uz boli co pracuju s CPU nekonecne rychlou a RAM nekonecne velkou. Nech sa paci nahlaste sa do kurzu LISP-u. Tam uz vsetky vase problemy vyriesili, dokonca rekurzivne.

                  1. mike

                    Re: Bulvární titulek

                    A to ako kam tie XML data chcete strkat. Na filesytem? Alebo ako BLOBY do databazy?

                    Většina soudných lidí by asi XML dokumenty pro tento účel strkala do XML databáze (např. eXist).

                    1. Palo

                      Re: Bulvární titulek

                      Alebo ich mozete strkat aj do SQL relacnej databazi (neviem ci viete ze existuju nadstavby relacnych databaz ktore nativne pracuju s XML). XML databaza, objektova databaza, je iba NADSTAVBA relacneho modelu ci sa vam to paci alebo nie. Neodpovedali ste ale na dalsie otazky v mojom prispevku.
                      Nerozumiem ale naco chce niekto NoSQL databazu. To ako by ste chceli XML data bez XSD, typov a XQuery. Ide to, ale nerozumiem kde je tu pokrok.

                  2. Martin MalýAutor příspěvku

                    Re: Bulvární titulek

                    Co takhle se vrátit zpátky k tomu článku a přečíst si to znovu a pomalu, místo rozčilování nad tím, že „lidi ztrácí soudnost“. Opravdu bych nechtěl, aby diskuse pokračovala na této úrovni, tedy kdo ztrácí soudnost a jak je kdo hloupý, že NEVIDÍ ty argumenty… Děkuji.

        2. krteQ

          Re: Bulvární titulek

          To je podle me na programatorovi – musi zvazit ekonomicky prinos toho, ze se opusti relacni DB a aplikace se prepise.
          Kdyz to vezmu do extremu, jakakoliv aplikace se da postavit na jednom plaintext souboru, je to jen otazka vykonu, bezpecnosti a nakladu :)

    2. Jan Kodera

      Re: Bulvární titulek

      Pokud tyto články povedou k tomu, že se několik lidí zamyslí a zjistí, že SQL není vhodná jako řešení na všechno, tak super. V podstatě každý buzz je o tom, vytvořit nadšení, které umožní vyzkoušet různé alternativy než se najde optimální nasazení technologie.

      NoSQL má dost problémů a je dost aplikací kam se nehodí, přesto by znalost jejich principů k vybavení každého vývojáře. Aby nemusel znova vynalézat kolo.

      To že SQL byla chycena v nedbalkách a na nároky webových aplikací prostě nestačila je jasné. Teď je jen otázka zda je možné ty enginy změnit. Věci jako zápis pouze na Master, složitý sharding a velmi zajímavá replikace. U původního článku se v diskusi vynořil nějaký pán a začal říkat, že je to celé chyba MySQL a že jiné lepší DB enginy by to zvládly. Otázkou zůstává na jakém železe a kolik stoji?

      1. backup

        Re: Bulvární titulek

        …zjistí, že SQL není vhodná jako řešení na všechno, tak super. …

        problem je, co nasadit misto sql, co vim, existuje jen hrstka produktu, o kterych nema ale bohuzel vetsina populace nejmensi potuchy …

        1. Martin MalýAutor příspěvku

          Re: Bulvární titulek

          … a proto tu o tom píšeme, aby mělo potuchy víc lidí.

          1. logik

            Re: Bulvární titulek

            No jenže todle z prominutím není nový produkt, ale znásilnění relační databáze.
            Nemám nic proti nerelačním db, ale todle imho šlo lépe řešit dobrou volbou databázového stroje.

            1. Martin MalýAutor příspěvku

              Re: Bulvární titulek

              Nečtete pozorně:

              „Existuje spousta databázových projektů, navržených tak, aby řešily problém ukládání dat s pružnou strukturou a vytváření indexů za běhu (například CouchDB). Bohužel žádný z nich není dostatečně používaný na velkých serverech, abychom se mohli někde inspirovat. V testech, které jsme četli a které jsme si udělali, se žádný z těchto projektů neukázal dostatečně stabilním či otestovaným do té míry, jakou potřebujeme.“

              1. logik

                Re: Bulvární titulek

                Čet sem diskusi i pod originálním článkem a tam několik lidí navrhuje např. oracle, který s vytvářením indexů on the fly nemá problém.
                IMHO autoři toho řešení vzali na danej účel nejnevhodnější databázovej stroj, zjistili že jim nevyhovuje, tak řekli, ahá, databázovej stroj se na to nehodí. Uděláme to tedy jinak…

                Ono 250milionů řádků zas není tolik. V podstatě i to, že ten „basmekt“ (byť evidentně chytře a dobře udělanej, ale svojí podstatou bazmekt), kterej nad MySQL napasovali, běží tak rychle, vypovídá o tom, že ty data se daj rozumně zvládnout.

                Tím nechci říct, že to jejich řešení není zajímavý, ni že možná z pohledu cena/výkon/rychlost vývoje bylo za jejich současné situace, kdy jim všechno
                běží na mysql, jedním z nejlepších ba dokonce nejlepší řešení. Je to ale drbání se levou nohou za pravým uchem.

                1. Martin MalýAutor příspěvku

                  Re: Bulvární titulek

                  Konstruktérské pravidlo říká, že není problém, který by se nedal vyřešit kladivem. A pokud pokus o řešení selže, znamená to, že máte malé kladivo.

                  Tohle je totéž: S trochou nadsázky lze říct, že není aplikace, jejíž datové problémy která by se nedaly vyřešit Oraclem na dostatečně výkonném železe. Ale to ještě neznamená, že to je řešení jediné, natož že je správné.

                2. Palo

                  Re: Bulvární titulek

                  Tak za 1) bazmekt LOOOOOOOOOOOOOOOL
                  za 2) Skor mi to pripada ze sice dobre poznali MySQL a zistili ze im nevyhovuje ale nepoznali nic ine. Nikto im neprezradil ze napriklad mame nejaky partitioning a mozno „bazmekt“ vznikol este v case ked partitioning nebol ;-)

            2. Mard

              Re: Bulvární titulek

              Znásilnění je pro mnohé taky prima činnost :-) Ostatně, kolikrát člověk musí znásilnit i Excel nebo OpenOffice aby se dobral požadovaného výsledku :-)

    3. Martin MalýAutor příspěvku

      Re: Bulvární titulek

      Jiří, ta formulace je reakcí na jednu diskusi tady na Zdrojáku, kde kdosi obhajoval SQL stroje argumentem, že „jsou za ta léta dobře vyladěné“ a že „na jejich vývoji pracují ti nejlepší vývojáři“ (s nevyřčeným „a chcete snad říct, že jste lepší?“). Já proti tomu mohu namítnout, že v době, kdy SQL vznikalo, byl relační model ideálním obrazem tehdejších HW možností. Doba se změnila, priority se posunuly, takže SQL v dnešní době není vždy a za všech okolností tou nejlepší volbou.
      Samosebou jsem dalek toho hlásat smrt RDBMS. Ale na druhou stranu si myslím, že relační model není posvátná kráva a že „ideová“ konkurence nezaškodí.

    4. Karel Minařík

      Re: Bulvární titulek

      Tak, já nevím, jestli tohle je správná platforma na nějakou diskusi, ale… některé z věcí které píšeš opakují „obecně rozšířené omyly“ a tak by možná stálo za to je proklepnout.

      > Leda prd, relační databáze jsou 1. podstatně silnější (kolik jazyků podporuje postgre? 7? 8? a kolik k-v storages? jen javascript),

      Mohl bys prosím tohle blíže vysvětlit? (Předpokládám, že se tím „podporuje“ nemyslí to, že se dá s databází pracovat v programovacím jazyce – protože s nimi samozřejmě lze pracovat z prakticky všech mainstream jazyků. Nebo ano? Taky předpokládám, že se tím nemyslí podpora pro starým slovníkem řečeno „stored procedures“ – např. CouchDB kromě JS podporuje pro views Erlang/Ruby/Python a všechny tyhle views servery jsou už napsané, Nebo ano?)

      > 2. lépe podporované (skutečnými firmami, ne skupinkami geeků po 3 lidech),

      To je ale nádherný exemplář manipulativního tvrzení! :) Mohl bys to prosím zase upřesnit? Protože jen letmý přehled: CouchDB – pod křídly Apache Foundation, core team > 5 lidí, pracují na něm lidi z IBM, nasazení v Canonical nebo BBC; Tokyo Cabinet – interní storage pro „japonský Facebook“ (mixi); Cassandra – Facebok; SimpleDB – Amazon; Redis – rozsáhlé nasazené v Githubu aj. A to pochopitelně nemluvě o Big Table a Google.

      > 3. vhodnější na 95 % aplikací (tedy všude tam, kde není nutné pracovat s terabajtovými objemy dat),

      Jak správně píše _několikrát_ Martin, *SQL na aplikace typu „blog“, „e-shop“, „pseudo-twitter“ se používají prostě jen proto, že „je na každém hostingu“, a že jsme na to zvyklí. To, že 95% (číslo také vycucané z prstu :) aplikací používá nějakou abstraktní vrstvu nad SQL (ORM nebo jen nějaký mapper), také svědčí o tom, že je tohle docela diskutabilní tvrzení.

      > 4. pokryté mnohem lépe vývojářskými nástroji,

      Ano, protože jsou tady XYZ let. To je _jediný_ důvod.

      > 5. dostupné na levných hostinzích,

      Ano, protože jsou tady XYZ let. To je _jediný_ důvod.

      > 6. něco málo v nich napíše i ta největší lama, co si myslí, že databáze = relační.

      Nenapíše, většinou bude používat nějakou abstraktní vrstvu nad tou „databází“, resp. SQL. Daleko snadněji bude pracovat třeba s MongoDB, které plní tu roli, jakou relační databáze docela často má (persistent storage a query pro objekty v programovacím jazyce) daleko lépe. Viz ukázky např. v článku http://railstips.org/…o-frameworks.

      1. Jiří Knesl

        Re: Bulvární titulek

        Ad jazyk: ano, myslím jazyk pro „stored procedures“. A mimo CouchDB jak jsou na tom ostatní k-v storages?

        Jestli se nemýlím, tak Apache foundation nenabízí „podporu“. Takovou tu podporu, co si můžeš zaplatit u Oracle, MySQL AB, popřípadě Microsoftu (a kterou nabízejí certifikovaní DBA po celém světě). Imho Facebook taky nenabízí placenou „podporu“. Amazon je na tom dobře, to je pravda (na druhou stranu Amazon nabízí i SQL se stejnou podporou). Github imho taky nenabízí placenou podporu. A co se Big Table týká, tak jsem nikde u Google nabídku placené podpory taky neviděl. Tokio Cabinet má afaik 1 stálého vývojáře, který se mimo to stará snad o další 2 nebo 3 projekty a to všechno při práci. Jestli o TCabinet uslyšíme ještě za 5 let, budu se velice divit.

        Myslím, že Martin i ty se v tomto mýlíš. Existují stromová data (kategorie-kategorie-kategorie), existují relační data (např. autoři-články-komentáře) a existují k-v data (seznam zboží na skladě), pak by se jistě našly i jiné typy dat, ale budiž. To, že schema-less k-v storage umožňuje uložit autory, blogposty a komentáře, ještě zdaleka(!) neznamá, že to tak je nejčistší možné řešení. Obdobně by šlo ukládat autory-články-komentáře do XML souboru a není to žádný argument pro opuštění ukládání relačních dat do relační databáze.

        Naopak velmi často přechod z SQL na k-v může být (minimálně pocitově) obdobou přechodu z 3. normální formy na 1., tedy věc, ze které každý slušný programátor dostane osypky a začne se poohlížet po zbrani.

        To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího. To není o zvyku, ale o naprosto racionálním vyhodnocení CO se pokoušíme KAM zapsat. Nehledám tady „nějaké možné“, ale „nejlepší možné“ řešení a to je imho velký rozdíl.

        Ad hostingy a nástroje a že jsou tu spoustu let. Každý rok vzniká milion různých databází, milion storage, milion databázových vrstev, milion šablonovacích vrstev, milion frameworků, každý druhý vývojář má pocit, že to udělá „znovu-lépe-radostněji“, proč po těch X letech se několik databází tak dobře drží na trhu? Prostě proto, že mají své místo. Nepochybuju, že nějaké noname k-v storages tu byly už v době COBOLu, jenže už v té době měly navrch uspořádaná strukturovaná data ve vzájemných vztazích … ehm, co mi to jen … aha, relační databáze!

        Ad lamy: jako lektor programování, který jezdí po firmách, vím, s čím (minimálně v PHP) vývojáři v Česku pracují. A povětšinou je to ne ORM, ale nějaký bastlobjekt s metodami: connect close query queryToArray queryToRow queryToSingle freeResult do kterého předávají SQLko, které si (v lepším případě) ručně chrání proti SQLi. Nějaký ActiveRecord (který už byl imho DataMapperem docela převálcován) považují často za „žhavou novinku“. Ti největší „profesionálové“ (což jsem doopravdy viděl) generují HTML přímo v databázi.

        1. Martin MalýAutor příspěvku

          Re: Bulvární titulek

          „Myslím, že Martin i ty se v tomto mýlíš. Existují stromová data (kategorie-kategorie-kategorie), existují relační data (např. autoři-články-komentáře) a existují k-v data (seznam zboží na skladě), pak by se jistě našly i jiné typy dat, ale budiž. (…) To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího.“ – není mi jasné, jestli tím polemizuješ se svým vlastním výrokem, že „relačních dat je většina“, nebo jestli se ho tím pokoušíš dokázat. :)

        2. okbob

          Re: Bulvární titulek

          Jestli správně chápu diskuzi, tak pro www programátory je asi nejpřirozenější stromová struktura – jejich prostorem je stránka – layout, která se rozpadá do komponent, kdy každá komponenta může obsahovat další prvky.

          Prakticky – strom je obecnější struktura než seznam, takže jakákoliv data lze transformovat do stromu – i když asi jediný prvek, který je skutečně rekurzivní jsou diskuze. U redakčních systémů nejsou pravděpodobné ad-hoc dotazy – co uložím, to chci dostat – pokud možno s co nejmenším úsilím, a co nejrychleji. To NoSQL databáze mohou nabídnout – navíc odpadá ORM.

          Ovšem nedovedu si představit např. větší e-shop postavený nad NoSQL databází.

        3. Palo

          Re: Bulvární titulek

          Veeeelice pjekne napisane. Tie skusenosti z lektorovania by mozno stali za clanok. Vyzera to zaujimavo. Best practice tu mame vela. Nejake CodeSmell su ale castokrat uzitocnejsie. Pretoze ludia vedia ze to co robian nemusia robit ako najlepsie sa da, ale v kazdom pripade ich zaujima comu sa vyhnut.

          1. Martin MalýAutor příspěvku

            Re: Bulvární titulek

            Ale to vůbec není špatný nápad! Co ty na to, Jirko? Agilní metodiky měly úspěch, nechtěl bys napsat něco o praktických zkušenostech z českých firem? :)

            1. Jiří Knesl

              Re: Bulvární titulek

              Je to bída. Snad všichni dělají něco, co do sebe míchá persistenci, objektové mapování, aplikační logiku, views, validuje se málo, někdy skoro vůbec, ošetřují se data málo, nebo se naopak všechno prožene htmlspecialchar­s(mysql_real_es­cape_string($pro­menna)) bez ohledu na to, kam ta data chtějí uložit/vypsat. Úpravy jsou pak peklo. Kód se duplikuje. Není vyjímkou, že soubory mají tisíce řádků. Že se výstupy chytají do output bufferu a pak přepisují reguláry. Objekty se často používají jen jako skladiště na funkce. O unit testech každý jen „ví“, že jsou „neekonomické a zbytečně zdržují“. Deployment se řeší Total Commanderem. O verzovacích systémech půlka firem asi neslyšela. Prototypování je … cože? a k čemu to jako je? Analýza se nedělá a když už se nějaká dělá, tak když pak klient 10* změní zadání, analýzu se nikdo měnit neobtěžuje. Zdrojáky jsou plné napevno zadaných URL a magických konstant. Štábní kultura neexistuje, každý vývojář to mastí, jak mu to jde z ruky. Když už nějaká štábní kultura existuje, stejně se ve zdrojáku objevují řádky dlouhé 300 znaků. Javascriptové frameworky už (konečně) nevadí, že se natahují. Teď ale děsně vadí natáhnout pár kilo CSS frameworku. Každý si myslí, že si napíš super framework (a že se zázračně vyhne tisícům chyb, které udělali jiní při pokusu o totéž). 3 vnořené foreache jsou košér, ikdyž by to šlo 3 foreachi za sebou. Nikdo nechce používat nové verze PHP, protože ještě nejsou v Debianu (který je zastaralý už v okamžiku, kdy stable verze vyjde – protože je to „bezpečnější“ – říkají hlavně ti, co potřebují bezpečný systém aniž by si sami zabezpečili vlastní aplikaci). Když už někdo chce open source framework, použije na svůj blogísek o 5 stránkách a 1 formuláři desetimegový Zend Framework (a pak zákonitě nadává, že mu to čas nešetří – ba právě naopak). Někdo nechce používat žádný framework, aby mu to náhodou nezpomalilo skript – hlavně u trivální aplikace s návštěvností nulanic na hostingu za 70 korun měsíčně (a pak tam nakonec stejně plácne Drupal, který bez cache musí udělat 300 dotazů, aby zobrazil homepage) – místo toho, aby si nageneroval takovou aplikaci v Cake, Railsech apod. za hodinu a půl. Bezpečnost je důležitá, až když to někdo hackne (navíc za ní klient nezaplatí, protože není vidět). Informační architekturu dělá většinou grafik, v horším případě programátor. Velká část klientů nepozná rozdíl mezi dílem od zkušeného vývojáře a nečím, co 14yrs bastlič MFAček z webtrhu splácá za noc. SEO se řeší až na hotovém webu (nehledě na to, že SEO je pro hodně lidí jen hezké URL, meta description a keywords (k čemu keywords???)). Nevidomí uživatelé a uživatelé zařízení s malým displejem pro některé vývojáře očividně neexistují.

              Byl bych sebevrah chtít na něco takového psát článek. Snad každý vývojář by si tam našel něco, za co by „mi to pak v komentářích nandal“. :)

              1. Martin MalýAutor příspěvku

                Re: Bulvární titulek

                Co by ti nandali? :) Vždyť to je pravda! Maximálně by ti psali, že „to přeci každý ví, že o tom není třeba psát články“, a na to se dá odpovědět: „Čím to tedy je, že když to všichni vědí, tak minimálně v polovině firem se tím neřídí?“ Tam není o čem diskutovat – zato je rozhodně na místě tyhle věci připomínat! Nebo si myslíš, že přijde někdo relevantní a nandá ti, že se mýlíš, že deployment Total Commanderem je ten správný (nebo tak něco)? :) Já bych se rozhodně za nějaké rozepsání přimlouval, a s chutí k tomu ještě pár věcí přihodím…

                1. Martin MalýAutor příspěvku

                  Re: Bulvární titulek

                  Pojďte, třeba Jirku přesvědčíme, že má smysl to rozepsat :)

                  1. Jaroslav Moravec

                    Re: Bulvární titulek

                    Já ti ani nevím, jestli to chci ještě jednou číst. Ti, kteří by si to měli přečíst , zamyslet se nad sebou a zařídit se líp, si to stejně nepřečtou, nebo v půlce ohrnou nos, protože jim to tak funguje a kecat jim do toho nikdo přeci nebude.

                    Těším se, že se jednou ráno probudím a svět bude ideální… ale netěším se na chvíli, kdy zjistím, že ještě sním.

                  2. Palo

                    Re: Bulvární titulek

                    Ja som za. Jirka nandej nam to. Take worst practice skoro ku kazdej vete co je v predchdzajucom prispevku aj s prikladom a pouckou ako sa tomu vyhnut.

              2. Martin Soušek

                Re: Bulvární titulek

                No ale co těm firmám poradíte?

                Klient takhle sice dostane šílený bastl. ale dostane ho za 15 000,– které ještě zvládne. Když to bude super aplikace od super kvalitního vývojáře, tak by sice byla kvalitní, ale za 100 000,–. Protože kvalitní vývojář něco stojí. To ale klient nepozná, protože on nepozná ani instalaci WordPressu od speciálního řešení na míru.

                Věřte tomu, že i řada firem by ráda dělala super kvalitní aplikace. Jenže když klienti neplatí dostatek peněz, tak nemůžou zaplatit ani kvalitní vývojáře. Vždyť i takové Symbio na „obyčejné“ kšefty (a někdy i ty neobyčejné) najímá studentíky za pár kaček, kteří to nějak zmastí. A nejsou to jen oni, Většina velkých hráčů to tak dělá. Kdybych mohl říct co říct nesmím, tak byste si trhali vlasy i s kořínky, co je všechno možné!

                Na druhé straně, díky nízkým cenám je internetová přítomnost firem v ČR neuvěřitelná. Tady má jakous takous prezentaci každý jouda. Například v Německu, Švédsku, Velké Británii (s těmito mám osobní zkušenosti) to tak rozhodně není. Protože tam vývoj stojí řádově více. Tam nemají stránky mnohé velké firmy, instituce, natož nějací živnostníci!

                1. David Grudl

                  Re: Bulvární titulek

                  To je pravda pouze zdánlivě. Ve skutečnosti záleží hodně na sebevzdělávání lidí. Dám příklad: protože výborně znám kvalitní framework, jsem schopen naprogramovat klasický CMS s fotogalerií na míru v řádu dní. Tedy rychleji, než bastlič, s tím, že můj kód je čistý, zabezpečení aplikace dokonalé, připravím i testy. Tedy mohu jej dodat ještě levněji, než bastlič (jiná věc je, proč bych to dělal, bavte se tedy spíš o výrobních nákladech). Ta pravá úspora času a nákladu se projeví ovšem tehdy, jakmile klient začne zadání upravovat.

                  Přitom knowhow je dnes dostupné jako nikdy předtím. Stačí se jen po něm natáhnout. Jenže učení bolí, lidé jsou líní a nedokáží uvažovat s mezikrokem. Raději teď budou dvě hodiny něco bastlit, než týden věnovat sebevzdělání aby později totéž zvládli řádově lépe za hodinu. Naučit se nebo přijmout něco nového není chuť.

                2. Jiří Knesl

                  Re: Bulvární titulek

                  Spousta věcí se dá dělat dobře a nezpůsobí to navýšení času. Ve výsledku třeba prototypování (protože se předem ví, co se má skutečně dělat), unit testy (protože pak zkrátí čas následného testování, navíc vede k lepší architektuře a pak k lepší upravitelnosti), použití verzování (založit repozitář je práce na 1 minutu), bezpečnost je dnes velmi dobře řešena ve frameworcích. Neutopit se ve frameworku znamená volit pro projekt odpovídající framework. Je nutné pracovat s know-how zaměstnanců, průběžně je školit a oni pak produktivně vyvíjejí o dva řády kvalitnější kód stejnou rychlostí – jen proto, že ti lidé vědí, kam co patří a ten kód dělí do správných tříd a pak už to „buší světelnou rychlostí“.

                  Symbio používá framework symfony, které vede k velmi dobrým návykům a spoustu problémů včetně bezpečnosti velice hezky (a produktivně) řeší. Nicméně mám zprávu i od nespokojeného klienta – kdo ví, zda to zrovna nebyla práce od nějakého studentíka. :)

                  Ad ceny v zahraničí. Je fakt, že třeba UK firma ufinancuje cokoliv (ale opravdu cokoliv, Britové mi v tomhle přijdou až jako ekonomičtí sebevrazi), ale jinak mi zbytek Evropy (mám nějaké – ale velmi omezené – zkušenosti s tímto z UK, Německa a Rakouska) o tolik dražší (nebo spíš ochotnější zaplatit o hodně víc) nepřijde. Ba jsem i potkal situace, kdy ceny byly shodné s ČR.

              3. Jens.cz

                Re: Bulvární titulek

                To me připomíná jednu nejmenovanou firmu :)

                Je to všechno jen o pěnězích, nikdo moc (natož malé firmy) nechce investovat (nebo si nemůže dovolit investovat) do věcí, které nejsou vidět (rozuměj, klient je nezaplatí), to je všude, co si budeme nalhávat …

                Ad zastaralá verze Debinu: mám zkušenosti jak se stable tak s testing verzí Debinu na serveru a věř Jiří, že používat testing na produkčním serveru si muže dovolit jen člověk, který zaměstnává administrátora serveru na fulltime. Denně nové aktualizace, občas se stane že i s chybou, navíc kvůli závislotem tě to nutí aktualizovat i balíčky, které nechces a podobně … To že se neřeší bezpečnost na straně aplikační logiky je věc z jiného soudku.

                1. Jiří Knesl

                  Re: Bulvární titulek

                  Honzo, ta nejmenovaná firma na tom ještě není tak zle. :))

                  ad Debian: právě proto já teď docela hájím nasazování rpm dister, jako je Centos (kromě jedné naprosto verze Centosu, která má velmi nepovedenou verzi PHP 5.1.6, no ale nad tím jsem se už dostkrát rozčílil při testování pro top.hostingy.cz). Většinou neděláš updaty denně a přitom jsou tam poměrně moderní balíky. Navíc existuji pro Centos snad 2 velmi prověřené a kvalitní repo s novými balíky (PHP 5.3.1 např.)

                  1. Jens.cz

                    Re: Bulvární titulek

                    no musis je delat velmi casto, ne sice dene, ale casto protoze ty baliky jsou testing, tudiz nejsou tak proverene a muze v nich (a byva) dost chyb

              4. Langi

                Re: Bulvární titulek

                Prosím každopádně rozepsat do (nekončícího) seriálu, klidně pod pseudonymem, nebo (se) budu odkazovat na tenhle komentář. Negativní příklady fungují.

                Kromě toho co se dělá špatně by mě taky zajímalo, jestli a jak se to dělá jinde dobře a jak (jestli) vyeliminovat ekonomické důvody (výmluvy?) typu „zalevno rychle a špatně, nebo draho pomalu a dobře, co si vyberete?“.

              5. Vojta

                Re: Bulvární titulek

                Děkuji Vám za naprosto geniální komentář :). Člověk neví, jestli se má smát, mlátit do hlavy nebo brečet.

        4. Karel Minařík

          Re: Bulvární titulek

          > Ad jazyk: ano, myslím jazyk pro „stored procedures“. A mimo CouchDB jak jsou na tom ostatní k-v storages?

          Počkat! Já myslel že to _víš_, když to tak rezolutně tvdíš :)

          Ty nosql databáze, které trochu znám já, nic jako „stored procedures“ nemají. A ani views Couche nemají striktně vzato nic společného s DB views nebo stored procs. Ten koncept je úplně jiný, „pojďme zaflákat HDD místo CPU“, atd.

          MongoDB má queries a indexy, Redis má specifické API. Je to jiný svět. Navíc např. pro oba tyto dva existuje množství wrapperů pro programovací jazyky, takže v Ruby lze i nad Redisem (!) postavit plnohodnotný ActiveRecord-compatible model.

          > Jestli se nemýlím, tak Apache foundation nenabízí „podporu“. Takovou tu podporu, co si můžeš zaplatit u Oracle, MySQL AB, popřípadě Microsoftu

          Aha, tak prosím napiš raději že ta a ta nosq databáze nemá „placenou podporu“. To je relevantní. Někoho to zajímá, někomu je to jedno. Mně je to třeba úplně a totálně jedno :) Mně zajímá, že mi do pěti minut poradí autor software na IRC kanálu, a když ten spí, tak mi poradí jiný kolega.

          > To, že schema-less k-v storage umožňuje uložit autory, blogposty a komentáře, ještě zdaleka(!) neznamá, že to tak je nejčistší možné řešení. Obdobně by šlo ukládat autory-články-komentáře do XML souboru a není to žádný argument pro opuštění ukládání relačních dat do relační databáze.

          A není to ani argument pro to, ukládat je do relační databáze. Modelovat vztah článek-komentář můžu pomocí JSON stejně jako pomocí vztahu 1:N. Nebo pomocí chytře napsaného map/reduce v couchi nebo query v redisu, a tak dále.

          Nic na světě „od přírody“ nevede k ukládání „ve třetí normální formě“.

          > Naopak velmi často přechod z SQL na k-v může být (minimálně pocitově) obdobou přechodu z 3. normální formy na 1., tedy věc, ze které každý slušný programátor dostane osypky a začne se poohlížet po zbrani.

          Hmm. Na to tu není prostor. Prakticky každý velký hráč na webu dneska denormalizuje jako o život, kvůli škálování, rychlosti, apod. (Google q=CAP+theorem, q=high+availa­bility, atd)

          > To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího. To není o zvyku, ale o naprosto racionálním vyhodnocení CO se pokoušíme KAM zapsat. Nehledám tady „nějaké možné“, ale „nejlepší možné“ řešení a to je imho velký rozdíl.

          > Ad hostingy a nástroje a že jsou tu spoustu let. … proč po těch X letech se několik databází tak dobře drží na trhu?

          Protože zvyk je železná košile. Ale ona ta dominance *SQL prostě skončí, a nejen u velikých hráčů. Když přišly Rails a Django, tak se taky všichni smáli a dneska je to v ASP.NET MVC okopírované i s komentáři nad metodami v controlleru.

          > … s čím (minimálně v PHP) vývojáři v Česku pracují. A povětšinou je to ne ORM, ale nějaký bastlobjekt s metodami: connect close query queryToArray queryToRow queryToSingle …

          Právě. Řečeno nyní ve spěchu bez obalu: mapují si nesmysly z MySQL na nějakou nativní strukturu jazyka, aby s tím mohli inteligentně pracovat. V MongoDB by jim bylo líp. Třeba na to někdy taky přijdou.

          1. Jiří Knesl

            Re: Bulvární titulek

            Ad otázka na ty jazyky. To je jen taková manipulativní otázka… :))

            Ad „můžu uložit tak nebo jinak“ je zase vzdálene tomu jak to můžu udělat nejčistěji. Obdobně JSON je jen zamaskovaná 1. normální forma, 1:N prostě patří do 2 tabulek, jinak to není „nejčistší možné“ řešení. A dokud nemám v té databázi joinovat terabajt dat s jiným terabajtem dat, NIC mě nepřesvědčí, že mám záměrně dělat zprasené řešení, když znám čisté řešení.

            A že můžu napsat nějaký správný reduce – stejně tak můžu napsat xpath dotaz na XMLkem, které si uložím do MySQL a přitom to neznamená, že je to ten nejlepší možný způsob. :)

            „Nic na světě od přírody nevede k ukládání ve třetí normální formě.“ – záleží na úrovni rozlišení. Můžeš mít objekt zeměkoule, kterou serializuješ a uložíš na disk. Nebo můžeš mít objekt člověk, těch uložíš 7 miliard. Nebo můžeš mít objekt buňka, kterých uložíš 2 na padesátou (to jen tak cucám z prstu). Relační databáze vychází z relační algebry, mají v matematice oporu a dají se mapovat na skutečné věci. Článek má omezený počet atributů o daném typu, komentář má omezený počet atributů o daných typech, uživatel jakbysmet, služební vozidlo také, budova také, nákupní košík také, objednávka také, poptávka z webu také, statistika přístupů také. Těch ustálených dat je spousta, kdežto potřeba ukládat „jednou 3 atributy, podruhé 200 tisíc, nikdy stejné typy“ je v přírodě jako šafránu.

            Velcí hráči denormalizují jen proto, že spravují objemy dat, které si běžný smrtelník neumí představit. To je problém, s kterým se tady v Česku potká možná tak seznam a pár obdobných. Ti ostatní jsou na mezi, kdy můžou škálovat pohodlně s Oracle, které je na takovou zátěž připravené.

            Ad „zvyk je železná košile“ – ale proč se stal zvykem? Když v té době už existovaly obdoby k-v (ostatně formát proměnných v lispu nebo APL by se mnohem snáz serializoval do k-v storage). Proč se SQL stalo standardem v době, kdy žádná železná košile nebyla?

            Djangu a Railsům jsem nikdy v životě neviděl nikoho se posmívat. Ty ano?

            Ad to mapování – právěže nemapují. Oni si naprosto zbytečně udělají objekt nad obyčejným voláním funkcí mysql_connect, mysql_query, mysql_close…, to nemá s objektovým programováním nic společného. Je to jen taková fasáda, na kterou když se zeptám, proč ji vlastně mají, nikdo neumí odpovědět.

            1. Karel Minařík

              Re: Bulvární titulek

              > A že můžu napsat nějaký správný reduce – stejně tak můžu napsat xpath dotaz na XMLkem, které si uložím do MySQL a …

              Takový XPath ale bude technicky i filosoficky vzato úplně jiného kalibru než např. map/reduce (+index, +btree, +incremental index build) v couchi.

              > Můžeš mít objekt zeměkoule, kterou …

              Omyl je v tom, že o tohle tolik nejde. Modelování jde prostě dělat různě a vlastně na tom ani moc nezáleží. Skutečný rozdíl je v reportování a ad hoc dotazech. Viz několik komentářů Pavla Stěhuleho zde v diskusi.

              > … běžný smrtelník neumí představ … tady v Česku potká možná tak seznam …

              Nene, stačí pracovat s netriviálním objemem záznamů v řádu jednotek miliónů a už to začne docela vadit, pokud se smíříme s představou, že „kupte si Oracle“ není řešení pro každého.

              > Djangu a Railsům jsem nikdy v životě neviděl nikoho se posmívat. Ty ano

              No jasně, dnes a denně :) Pravda, za ty roky se to docela zlepšilo. A mimochodem, ten úplně _hlavní_ argument „proti“ je právě ten „je málo podpory na hostingu“. Ty české hostingy by měly dostat nějaký grant z investičního fondu EU na rozvoj konkurenceschop­nosti, jak to tak vypadá. To je vyložená žába na prameni :)

              1. Aleš Roubíček

                Re: Bulvární titulek

                Aha tohleto :) jedna z nejhorších věcí, kterou rychle mažu už v globální šabloně VisualStudia. Osobně zastávám názor, že komntář je zastaralej, jen co ho dopíšeme, obvzlášt komentář s Routou je věc která zastará za chvilku. Navíc, když mám aplikaci, která má routy lokalizované do víc jazyků, tak to strácí smysl úplně… :) Možná si někdo v Redmondu myslel, že to je dobrej nápad, já to s ním ale nesdílím…

                1. Karel Minařík

                  Re: Bulvární titulek

                  Jasně, „zkopírovat i s komentářema“, to byl jen takový obrat, něco jako „sežrat i s chlupama“ .)

          2. okbob

            Re: Bulvární titulek

            Nic na světě „od přírody“ nevede k ukládání „ve třetí normální formě“.

            Souhlasím s tím, že záleží na detailu. Příklad – knihovna – pokud budeš řešit domácí knihovnu, pak 3NF je něco, k čemu by se mohl snadno dostat i neškolený programátor. Pokud začneš hypotetickou absolutní knihovnou – tak pravděpodobně začneš mnohem dřív řešit hierarchii – a dost možná, že skončíš u nerelační db.

            Souhlasím s tím, že 3NF není samozřejmá – lidé jsou zvyklí „škatulkovat“. Souhlasím i s tím, že s denormalizovaná data můžeš načítat o dost rychleji – pokud se ovšem pohybuješ po jedné vytyčené koleji. S NF mám mnohem větší možnosti dotazování, analyzování dat – což se bere i jako jedna z základních funkcí db.

            Možná by stačilo konstatovat, že pro redakční a podobné systémy je databáze nepotřebná – úplně postačuje persistentní cache. Myslím si, že to je to, na čem tu možná trochu ztroskotává diskuze – lidé, kteří pracují s DB si představují pod pojmem databáze trochu něco jiného – a umí s databázemi jiné kousky, než programátoři redakčních systémů.

            1. Martin MalýAutor příspěvku

              Re: Bulvární titulek

              K tomu poslednímu odstavci: Mějme na paměti, že Zdroják je magazín o WEBOVÝCH technologiích, a ty „Opravdové Databáze“ (jak tu někteří komentátoři občas použijí příklad s bankovními aplikacemi v Javě) jsou na webu kuriozitou, nebo přinejlepším výraznou menšinou. Jejich schopnosti práce s DB nikdo neumenšuje ani neupírá, jen – pro web je to většinou „kanón na vrabce“ a priority webové aplikace jsou, přese všechny společné základní řemeslné poučky, přeci jen trochu někde jinde než priority bankovní aplikace. Takže: Nechme „trochu jiné představy o DB“ těm, kdo je mít mohou, a vraťme se zpátky na web. :)

              1. okbob

                Re: Bulvární titulek

                Trochu mi nesedí termín „webové aplikace“ – v kontextu o kterém se bavíme. Z hlediska správy dat mi přijde docela zásadní si všímat rozdílů mezi redakčními systémy, eshopy a intranety. Vyjma redakčních systémů si nedovedu představit systém, který by se obešel bez klasické relační databáze. Přijde mi, že účelově klamete tvrzením „webová aplikace = redakční systém“.

                1. František Kučera

                  Webové aplikace

                  Ono „webové aplikace“ je vůbec trochu divná kategorie, když se bavíme o ukládání dat – to je jako zohledňovat, jestli ta aplikace má GUI napsané pomocí GTK nebo Qt, na tom přece (z hlediska dat) nezáleží. Takže souhlas – daleko víc záleží na smyslu té aplikace (redakční systém, účetnictví, skladiště informací…) než jestli to má webové rozhraní (protože to má dneska kde co).

                  1. Martin MalýAutor příspěvku

                    Re: Webové aplikace

                    Webová aplikace je to, co je navrženo jako aplikace primárně ovládaná přes web. Toto implikuje některé další vlastnosti, jako například orientaci na přístup více uživatelů najednou ve stejném čase pomocí nestavového protokolu HTTP, z čehož vyplývají zase určité požadavky a omezení, které mají v důsledku vliv na formu ukládání dat. Je s tímto vymezením nějaký problém? Nesouhlasíš s tím? Myslíš si, že je jedno, jestli je aplikace určena primárně pro desktop (~1 uživatel) nebo pro web a že to nijak neovlivní formu ukládání dat?

                    (Ponechme stranou všechny mezistupně, jako „vnitropodnikové IS“ a spol.)

                    7. 1. 2010 13:47 redakčně upravil Martin Malý, důvod: Rozdělený komentář
                    1. František Kučera

                      Re: Webové aplikace

                      „Myslíš si, že je jedno, jestli je aplikace určena primárně pro desktop (~1 uživatel)“

                      To jsem nikde nenapsal :-)

                      Myslel jsem tím klient/server aplikace – s těmi pracuje taky víc než jeden člověk zároveň. Jak se bude lišit třeba účetnictví podle toho, jestli má webové rozhraní nebo tlustého klienta. Resp. jak se bude lišit struktura jeho databáze (ať už jakékoli)? A bezestavovost HTTP protokolu se snad vyřeší někde nahoře a na datovou vrstvu její následky přece nedopadnou, ne?

                      „(Ponechme stranou všechny mezistupně, jako ‚vnitropodnikové IS‘ a spol.)“
                      Jo, už asi vím, jak to myslíš.

                2. Martin MalýAutor příspěvku

                  Re: Bulvární titulek

                  Přijde mi, že účelově klamete (pokud se tedy chcete bavit na této úrovni) zjednodušováním – Facebook, Google Maps, GMail, LinkedIn, Digg, Websnapr, Photoshop.com, Twitter, Bit.ly, Youtube nebo zmiňovaný FriendFeed patří přesně kam? Eshop, intranet nebo redakční systém?

                  1. okbob

                    Re: Bulvární titulek

                    můj výčet není určitě úplný. U řady aplikací nenajdete jasné hrany – viz např. Google Wave – aplikace z Vašeho výčtu rozhodně nejsou ani eshopem a nejsou ani intranetem. Odpovím otázkou – na kolik je Google Maps typickou www aplikací (bez ohledu na to, že používá speciální ro db)? Pro mne jsou některé z Vašeho výčtu – jednoduché, nebo složitější redakční systémy – vložíte obsah, který v té či oné formě prezentujete.

                    1. Martin MalýAutor příspěvku

                      Re: Bulvární titulek

                      Většina toho, co na webu je, a to včetně eshopových frontendů (a naprosté většiny intranetů)k, je ve stylu „uložím data – prezentuju data“. Vaší terminologií to jsou tedy „redakční systémy“ – a můžeme tam klidně zahrnout vše, co jsem zmínil. Čímž se vracíme k té rovnici „(noje) webová aplikace == (váš) redakční systém“, kterou jste nazval „klamáním“.

                    2. Martin MalýAutor příspěvku

                      Re: Bulvární titulek

                      Většina toho, co na webu je, a to včetně eshopových frontendů (a naprosté většiny intranetů), je ve stylu „uložím data – prezentuju data“. Vaší terminologií to jsou tedy „redakční systémy“ – a můžeme tam klidně zahrnout vše, co jsem zmínil. Čímž se vracíme k té rovnici „(moje) webová aplikace == (váš) redakční systém“, kterou jste nazval „účelovým klamáním“.

                      7. 1. 2010 14:04 redakčně upravil Martin Malý, důvod: Oprava překlepu
              2. Palo

                Re: Bulvární titulek

                A co je ako kanon na vrabce? SQL databaza? Na com ze to povacsinou bezia web aplikacie? Ja som myslel ze nad MySQL co je SQL relacna databaza. Co mi uslo?

                1. Martin MalýAutor příspěvku

                  Re: Bulvární titulek

                  Ad Kanón na vrabce: „Myslím si, že to je to, na čem tu možná trochu ztroskotává diskuze – lidé, kteří pracují s DB si představují pod pojmem databáze trochu něco jiného – a umí s databázemi jiné kousky, než programátoři redakčních systémů.“ TYHLE databáze jsou kanón na vrabce.

                  1. Palo

                    Re: Bulvární titulek

                    Fakt som asi mimo ale:
                    – Pouzivame objectovo-relacny mapovaci nastroj (hibernate/JPA)
                    – DEV na MySQL/PostgreSQL
                    – Test na PostgreSQL
                    – Rutina PostgreSQL (a asi bude Oracle)
                    – Prave teraz vytvarame specializovany redakcny system na objednavku
                    – Sam som vytvaral a robil architekta na XML databazach, Objektovych databazach, Messagingu, LDAPoch, …

                    No a teraz, vsade som za tym videl alebo to fungovalo na relacnym modelom. Myslite ze co pouzivaju nativne objektove databazy (LDAPy, XML databazy)? Bud boli postavene nad SQL databazou alebo vnutri bol pouzity relacny model. Mam dlhorocne skusenosti (aj ked teraz nepouzivam) s ODBMS Versant. Ten sa da programovat na viacerych vrstvach kde najvyssia je objektova a najnizsia je asi nieco na styl k-v. No a cuduj sa svet druha zospodu je nieco ala SQL pre potreby reportigu, dotazovania, … .

                    Kde su vyhody pouzitia NoSQL? Podla mna je to krok spat a to je to co sa tu snazim zistit, co prehliadam ze nevidim tu vyhodu?

                    Ten Versant bol super a patri ku spicke objektovych databaz. Dnes ho ale kombinacia objektovo mapovaci framework + relacna databaza porazi v comkolvek. Relacna databaza + SQL tu bola a zostane veeelmi dlho. Mozno s nejakymi XML, ci objektovymi nadstavbami ale je to nieco ako chytrejsi filesystem. Nic viac nic menej.

                    Sorry aj za niektore ine prispevky ak boli trochu off topic ale ludia sa to rozpisuju o takych veciach ze sa mi oci krizia.

                    1. backup

                      Re: Bulvární titulek

                      zajimalo by me, kolik je vam let.

                      Ja jsem takovy hype uz zazil nekolikrat. Jako C programator jsem se take ptal, jake vyhody jsou v tom c++ a objektove orientovanem pristupu, co jsem asi prehledl. Dnes, po 20 letech Vam muzu odpovedet, ze jsem se nemylil. Programy se nestaly lepsi, jistesji a projekty nejsou levnejsi. Ani jedno, co se slibovalo nenastalo. Ale presto jsem musel v dalsich zamestnanich rikat, jak v te c++ valim, abych mohl prezit.

                      Podobne to bylo pred 10 lety. Perl. Byl jsem vazenym programatorem, protoze jsem si precetl tu syntaxi a u 5-teho jazyka clovek zjisti, ze je vsechno stejne. Dnes je perl pro smich. Ani to nikde nerikam, co vsechno jsem v tom napsal. Java je in a python ci jak se ostatni vsechno jmenuje. Zrovna tak dotnet.

                      Mohu vas ujistit, neprehledl jste nic. Protoze se na tu problematiku divate pouze z technicke stranky. Budete se ale divit, az se Vas u pristich projektu budou ptat, jestli ovladate NoSQL. A ja vam garantuji, ze to zakaznikovi slibite a po podepsani kontraktu se stavite v knihkupectvi a koupite si o tom NoSQL nejakou knizku.

                      1. Palo

                        Re: Bulvární titulek

                        > Ja jsem takovy hype uz zazil nekolikrat.

                        Tak to ano, vela a hlavne na GUI. Co sa tyka ‚database hype‘ ja si pamatam hlavne objektove a XML databazy a to tlacili velke komercne firmy. Vysledok – z mojho pohladu nic. Vylepsili sa nadstavby nad relacne bazy a kara ide dalej. Vtipne mi iba prislo ze to fakt boli nadstavby. Toto NoSQL je akysi suteren databaz. Nieco co by mozno malo byt v jadre databazy nie nad nou. Niekde som uz pisal ako to mal vyriesene napr Veritas kde tento k-v level bol pod SQL level a tam to aj patri.

                        > Jako C programator jsem se take ptal, jake vyhody jsou v tom c++

                        Myslim ze OOP dekompozicia nieco priniesla. Kniznice, riadenie pamate, …

                        > Podobne to bylo pred 10 lety. Perl.

                        Toto obdobie ma preskocilo. Presiel som od REXX, Ruby (BTW Ruby je hrozne stary jazyk), Perl, Python velmi rychlo a dlhodobo som sa venoval Jave. Uz od prvych verzii nakolko som vychovany Basicom, dBase, FoxBase, C/C++, SQL, Ingres 4GL.

                        > u pristich projektu budou ptat, jestli ovladate NoSQL

                        V prvom prispevku som dufam dostatocne objasnil preco sa ma to dufam nikto nikdy neopyta. Naviac to dokazem dobre technicky vyvratit. Ale uz sa ma pytali aj na .Net, a ten je myslim niekde inde ako NoSQL, a odolal som :-D. Myslim ze tak ako nevymreli COBOL programatori tak uz asi aj ja umriem nad Javou.

    5. jos

      Re: Bulvární titulek

      … přece jen poněkud staršího data …

      jasný, nevěřte ničemu, čemu je přes třicet (teda čtyřicet, ale to tam nepasuje)

      btw. moc se mi líbí, jak se v tomhle threadu žongluje se slovem relační

  8. krteQ

    vytvareni/odstranovani indexu

    Je vyrazne rychlejsi na innodb pluginu (neplest se standardnim innodb), protoze se uz nemusi rebuildovat cela tabulka. Problemem zustavaji unikatni a primarni klice.

    Trochu nechapu, ze jim prepinani master/slave pri udrzbe dela problemy, ale asi maji opravdu svizny vyvoj :)

    1. Martin MalýAutor příspěvku

      Re: vytvareni/odstranovani indexu

      Ty problémy jsou v článku docela dobře popsané: Jsou to operace, při nichž se může tolik různých věcí (s prominutím) podělat, že člověka představa, že příští týden bude muset celá infrastruktura tohle opět podstoupit, spolehlivě odradí od toho, aby nějaké změny dělal.

  9. Lukas

    NoSql ? To už tu jednou bylo.

    Jeden NoSql systém tady máme už 15 let – je to LDAP, vytvořený pro případy, kdy záleží na rychlosti čtení, k zápisům dochází velmi málo a dočasné nekonzistence mezi kopiemi je přijatelná.
    Na jednom projektu na kterém jsem pracoval jsme s LDAPem měli problémy – pracovalo se s ním velmi těžce, přínosy byly zanedbatelné oproti omezením.

    Jsem rád, že se o NoSql začalo mluvit, že vývojáři přestali vnímat sql jako jedinou volbu. Znám případ, kdy vývojář indexoval několik terabyte textové informace pomocí MySql:). Nicméně, tohle byl speciální případ, 95% procent projektů nejspíš noSql nepotřebuje a naopak ocení výhody ACIDu, abstrakce, řešení relací. Za tyhle skvělé features zaplatí určitou cenu, ale většinou ta cena bude zanedbatelná oproti reimplementaci byť i podmnožiny featur které SQL nabízí.

  10. Michal Blaha

    Know-jow/Technologie/Cas/Zdroje - to je oč tu běží

    Přelétl jsem zrychla všechny a některé kvalitní komentáře i podrobněji.
    Nebudu přikládat pod kotlík „SQL“x“k-v db“.

    Jen pár poznámek, které zapadly v diskuzi a stoji za to je připomenout:
    1) článek je case study. Popis řešení konkrétního problému v konkrétním prostředí.

    2) Pánové ve FF byli v situaci, kdy narazili na realné limity relační DB (ne technologické, ale praktické) a museli v omezeném čase, s omezenými prostředky (kapacita) a danným know-how prokázat výrazné zlepšení.
    A to u projektu, kde je datová struktura velmi a často modifikována (což si přiznejme není pro relační DB a navázaný kód situace ideální).

    (doporučuji jako jiný příklad historii změn architektury backendu Twitteru. Tuším 5 změn za 3 roky)

    3) Omezené knowhow je poměrně zásadní omezení. Pokud má team letité zkušenosti s MySQL, tak týdenní školení Oracle na 5× výkonnější HW je k ničemu. Chybí ty zkušenosti, které se dají rychle pouze koupit (člověk). A teď mi na světě ukaže, kolik lidí má špičkovou znalost Oracle, na prudce roztoucí bázi dat s neodhadnutelnou zátěží (rostoucí spíše exponenciálně než lineárně).

    Tato case study je podle mne krásnou ukázkou dobré racionální a pragmatické úvahy, jak dosáhnou „přijatelného řešení“ v omezeném prostoru.
    A současně důkazem, že toto je _jedna z cest_ kudy se dá vydat a není to cesta slepá. To stojí za ocenění.

    Můžeme diskutovat zda zůstat u MySQL bylo lepší než přejít na Oracle či cokoliv dalšího. Můžeme se dohadovat, jak moc strukturovaná jsou data kolem nás či kolem měsíce. Ale je to jen hezká intelektuální rozcvička.
    Pravda se ukáže pouze na bojišti. A to má k teorii hodně daleko.

  11. David Grudl

    My programátoři si rádi život komplikujeme

    Vždy je zajímavé si přečíst, jak hackují technologie tam, kde mají natolik vytížené stroje, že si to ani neumíme představit, ale bylo by chybou z toho vyvozovat obecné závěry platné pro „nás dole.“

    Ale když už téma NoSQL bylo nakousnuto… V IT platí, že život si komplikujeme sami.

    Je fajn naučit se uvažovat i mimo mantinely, které jsme si sami uměle vytvořili. Např. si uvědomit, že neplatí, že pro ukládání dat jsou SQL databáze a že 4. normálová forma je nejčistší způsob organizace dat, nýbrž že SQL databáze jsou jen jedním z možných úložišť a normálová forma platí hlavně v nich. Denormalizace, používání nerelačních úložišť atd – to jsou zcela korektní záležitosti.

    „SQL fuj, NoSQL huj“ je jen hloupá móda, jak už módy bývají, protože jen jinak nastavuje mantinely.

    Uvažování v mantinelech a podléhání módním výstřelkům způsobilo, že svět není schopen uspokojivě vymyslet, jak zkombinovat objekty programovacích jazyků s relacemi databází. Ba co víc, už v případě prostého eshopu s velkou variabilitou zboží může i zkušený architekt tonout. Přitom stačí na věc nahlédnout s větším odstupem nebo bez módních serepatiček a řešení se ukáže jako triviální.

    …nojo, ale my v IT si rádi život komplikujeme sami :-) Borcům z FriendFeedu velké plus za schopnost hledat netradiční cesty!

    1. Palo

      Re: My programátoři si rádi život komplikujeme

      Je tu ale niekolko ale. Bavit sa o problemoch normalnej formy nema zmysel. Ta je v poriadku a ktorakolvek sa da zachytit v SQL databaze (aky bordel si tam urobite je vasa vec). Vyssie normalne formy prinasaju iba vyssie usporiadanie a poriadok ale nikto vas nenuti ich pouzivat.
      NoSql databazy vyzera ze maju iba technologicku vyhodu proti niektorym SQL databazam. Tieto nevyhody mozu byt v buducnosti v SQL databazach odstranene (napriklad pridanie nullable stlpca by nemuselo trvat nic).
      Co je vtipne ze aj na tu NoSQL databazu vyuzivaju naspodu SQL databazu takze si vlastne sami dobrovolne orezavaju funkcionalitu ktoru maju.
      Ja som sa naucil ze SQL a relacny model je akysi dobry zaklad vsetkeho. Pouzivali sme aj nativne XML databazy, aj nativne objektove databazy. Kazda ma nieco do seba ale vsetko sa to da realizovat nad beznou relacnou SQL databazou. Pre mna je SQL databaza nieco ako chytrejsi file to je vsetko.
      Ja pouzivam Javu cez Hibernate/JPA a pracujem s Java objektami. Ked je treba napise sa nativne SQL query alebo nativny SQL update. Nevidim ziadny hlbsi vyznam v tom ochudobnovat sa o SQL na nizsej vrstve. Co by som tym akoze ziskal?

  12. Bob

    Kladivem na sroubecek

    No jo, kdyz se pouzije dostatecne velke nasili, lze pomoci kladiva i sroubecek zatlouct. Jestli by ale nebylo lepsi pouzit primo vhodny nastroj, at uz ve forme poradneho designu, takze nemusim kazdou chvili delat alter table, poradne sql databaze, takze alter table netrva par hodin nebo vhodne ne-sql databaze.

    1. Almad

      Re: Kladivem na sroubecek

      Aplikace typu FF se vyviji neustale, tam je alter table nutnost bez ohledu na kvalitu designu.

      1. Martin MalýAutor příspěvku

        Re: Kladivem na sroubecek

        K tomu jen připomenu, že „neustálá změna“ je na webu realitou snad ještě víc než v jiných IT odvětvích. Reflektovat takovéhle změny učí metodiky agilního vývoje, které jsou v tomto směru téměř protikladné onomu klasickému postupu, kdy se udělá důkladná analýza a do té se už nezasahuje, protože zadání je jednou dané a pevné. Udělat web jako „daný a pevný“ je většinou chyba.

        1. Almad

          Re: Kladivem na sroubecek

          Ja jen dopredu reagoval na protiargument „takov CMS firmy se udela jednou a pak se na ni rok nehrabne“.

          IMO neni spatne obcas vymezit, kdy se jedna klasicky o startup a vyvijenou sluzbu a kdy se doda jednorazove neco na zakazku (jasne, i do toho se nakonec hrabe, ale podminky jsou proste jine).

        2. František Kučera

          Re: Kladivem na sroubecek

          Asi by to ale chtělo rozlišovat „weby“ a „webové aplikace“. U aplikací platí to, co píšeš, ale u těch webů se moc nového vymyslet nedá – tam se mění design (prezentační vrstva → tudíž všechno pod tím může zůstat) a přidává obsah (články, fotky…) změny struktur jsou ale minimální – např. web, který má prezentovat firmu, může stát na prakticky stejných strukturách jako před deseti lety, jen se mu dá moderní design a aktuální data. Podobné to bude u webů zaměřených na obsah – jejich „core byznys“ je psát pěkné články, třeba cestopisy, to je důvod, proč tam lidi chodí. Takže tam se taky nebude měnit struktura moc často – hlavně bude přibývat obsah a občas se modernizuje vzhled.

          1. Almad

            Re: Kladivem na sroubecek

            Ano, mluvil jsem o aplikacích. Jsem přesvědčen, pro 99% „webu“ není důvod nenasadit nějaké krabicové řešení a tudíž nemá moc smysl to řešit (prostě se použije takové datové úložiště, které to podporuje…pro většinu těch webů je to stejně – specielně v ČR – jedno).

  13. Vojta

    Pozor na to!

    Zdravím všechny. Tento článek i pár podobných jsem si přečetl, ale nemyslím si, že je toto správná cesta. Relační databáze je dělaná jako relační databáze, je pro tento účel navržená, vytvořená, optimalizovaná a ozkoušená. Ukládat v ní samozřejmě lze všelicos, ale proč pro toto „všelicos“ používat právě relační databázi? Není jednodušší naimplementovat nový (vlastní) databázový stroj určený k pro ukládání takových dat?

    Probíhala tu i obecnější diskuse o ORM. ORM je mapování objektů na relační model, takže už z principu je to takový „bastl“, který míchá dva různé pohledy na tutéž věc. Proto jsou s tím (a vždycky budou) problémy. Když je tedy potřeba používat objektový model, proč nepoužít objektovou databázi? Nebylo by moudřejší věnovat více energie zde?

    Ano, je to tady kvůli kompatibilitě. 90% všech systémů se nevytváří od nuly, ale modifikuje. Proto tu s námi relační databáze ještě chvíli budou. Z toho důvodu je také nemoudré v tomto čase u nějaké firmy zavádět navržené NoSQL řešení, protože je nové a za pár let může někdo přijít na to, že je to blbost, a bude se snažit „rozházeným“ datům znovu dát nějaký řád a smysl.

    Nebráním se pokrokovým myšlenkám a experimentům – právě naopak, sám si rád hraju. Proto přeji hodně štěstí při práci s konceptem NoSQL databáze, ale podle mě tato bublina brzy splaskne. Toto je pouze můj skromný názor :).

    1. František Kučera

      Re: Pozor na to!

      „Není jednodušší naimplementovat nový (vlastní) databázový stroj určený k pro ukládání takových dat?“

      Já jsem tedy vlastní databázový stroj nikdy nepsal, ale řekl bych, že jednodušší to nebude. Správnější/čistější možná, ale jednodušší určitě ne. (A v rámci běžného projektu je něco takového nereálné). Důležité jsou výsledky, ne řeči – takže pokud jim to takhle funguje a aspoň rok fungovat bude, tak bych to považoval za dobré řešení (i když mi zrovna nesedí). Prostě vyřešili projekt, splnili úkol a to se počítá – my se tu jen hádáme v diskusi :-)

      „takže už z principu je to takový „bastl“, který míchá dva různé pohledy na tutéž věc.“

      A jak je nemíchat, když tu relační databázi prostě musíš mít? Nepřevádět záznamy na objekty, ale rovnou z DB generovat HTML? To je pěkná prasárna. Nebo na objekty rezignovat a záznamy skrz naši aplikaci proplouvat jen jako pole textů a čísel? To mi přijde hrozně nepohodlné a vedoucí k chybám. Nebo generovat v databázi XML (třeba taková PostgreSQL to docela hezky umí) a pak ho prohnat přes XSLT do (X)HTML. Jo, to by asi šlo.

      Většinou se s tím ale člověk musí nějak poprat – na jedné straně má objekty, na druhé relace – pak se použije buď ORM, jakožto obecný framwork, kterému předhodíme akorát mapovací metadata (jaké tabulky na jaké třídy), nebo ORM nepoužijeme a napíšeme si to mapování ručně jako nějakou DAO vrstvu.

  14. Sebastian

    Hezký článek

    Zdravíško,
    hezký článek, ale asi jsem jej moc nepochopil… :(
    Každopádně, neni tohle pomalé? Přeci jenom, hledáme třebas Field uživatele Franty, takže projdem tabulku index_user_id ze které dostaneme entity_id, pak musíme nahládnou do tabulky entities a získat tělo (slovník) entitity na základě indexu; ze kterého stejně jestě musíme získat data, která nás zajímají..?
    Proč prosě nejde použít tabulku?
    CREATE TABLE entities (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    feed_id BINARY(16) NOT NULL,
    user_id BINARY(16) NOT NULL,
    title VARCHAR(64) NOT NULL,
    link TINYTEXT NOT NULL,
    posted TIMESTAMP NOT NULL,
    updated TIMESTAMP NOT NULL,
    UNIQUE KEY (feed_id),
    KEY (updated)
    ) ENGINE=InnoDB;
    Teď jak to píšu, tak si začínám uvědomovat normální pravidla, takže „jen“ proto?

  15. Martin Kavalec

    relační model vs. noSQL

    Rozhořela se tu debata o tom jestli je noSQL hype nebo něco užitečného, jestli je používání relačních databází jen zvyk a zaběhaná praxe.
    Vždycky se hodí se zamyslet, jestli není lepší něco udělat jinak, přijít s novým a neotřelým řešením a taky se stojí za to zamyslet, oc co tím přijdeme.

    Relační databáze tady nejsou několik desítek let jen ze zvyku, je pro to dobrý důvod. To, že realitu „rozbíjíme“ a „natloukáme“ do relačního schématu má velkou výhodu v tom, že se ta „rozbitá“ realita pak dá poskládat i jinak, můžeme se na takto uložená data podívat několikerým způsobem a relační databáze jsou desítky let optimalizovány na to, aby data uměly poskládat tak, jak si zrovna vzpomeneme.

    U jednodušších aplikací je možné, že to nepotřebujeme, že aplikace bude pracovat s daty stále stejným způsobem, že si ušetříme práci s modelováním a ukládáním do relací, s ORM… na webu se asi najde dost příkladů. Ale je potřeba se třikrát zamyslet, jestli se to někdy nevymstí.

    Provozujeme loyalitní program, členové si mohou na webu objednávat dárky, ty je třeba objednat od dodavatelů a rozeslat členům programu. Pokud objednávky uložíme do relačního modelu, stačí jeden select s group by, aby bylo jasné kolik čeho musíme objednat. Jenže když si weboví programátoři usnadní práci a celou objednávku uloží do databáze jako objekt přes php_serialize, máme o zábavu postaráno… e-shop může být ukázkový příklad, kde se NoSQL moc nehodí, ale tohle se fakt stalo…

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=3150