56 komentářů k článku Zend Framework: Úvod do frameworku:

  1. DD

    Prečítajte si nasledovný seriál a naučte sa modernému programovaniu pomocou ZEND frameworku.

    ‚Prečítajte si nasledovný seriál a naučte sa modernému programovaniu pomocou ZEND frameworku.‘
    nezda sa mi ze ZF zabespecuje moderne programovanie… pokial chcete naozaj kvalitne OOP, php 5.3 (5.4) a nie nejaky ztary a robusny framework tak by som urcite nevolil ZF…

  2. dik

    ktery framework ?

    Ahoj všem,
    je tu někdo fundovaný, kdo má praktické zkušenosti s ZF, Nette a Django a mohl by vypíchnout výhody/nevýhosy výše zmíněných?
    Rad bych se naučil nějaký fw a umím python (php jen trochu) tak si rád nechám poradit.
    Dík

      1. Erino72

        Re: ktery framework ?

        Myslis si ze python je lepsi/ rychlejsi na weby ako php ktore je na to asi lepsie pripravene?

        1. srigi

          Re: ktery framework ?

          Python je mocnejsi jazyk ako PHP. Za vsetky spomeniem napr. operator yeld. Netvrdim, ze s PHP sa neda vyriesit nejaky problem, ale ak niekto ovlada mocnejsi jazyk, pride mi to zvlastne downgradovat.

          O PHP sa tvrdi, ze je rychlejsie ako Python alebo Ruby, na druhu stranu sa ale aj tvrdi, ze PHP nevyskalujes tak jednoducho ako tie dva jazyky. Kazdopadne (ako mi raz povedal nas admin), az raz budes mat na stranke 100000 unikatov, budes riesit uplne ine problemy ako volba jazyka.

      2. Michal Májský

        Re: ktery framework ?

        Já mám zkušenosti s Nette, Symfony a Djangem.

        Nette mám rád na menší projekty. Jsem v něm asi nejrychleji schopný udělat menší webík (ale možná je to tím že s ním mám nejvíc zkušeností).

        Symfony je robustní FW, který bych volil pro velký projekt kdyby musel být psán v PHP.

        Django je v současnosti můj favorit. Nejvíc se mi líbí na něm líbí integrované ORM, které mi opravdu sedí. Oproti Doctrine s jehož konfigurací a integrací do frameworků jsem vždy bojoval a nakonec ho raději nechal plavat.

    1. vidya

      Re: ktery framework ?

      mam skusenosti v php len so symfony2 a nette, ale ak ti mam poradit, pozri sa na dokumentaciu k doctrine/propel/di­bi/whatever a potom na django orm a myslim ze budes mat jasno :-)

    2. hurvajs77

      Re: ktery framework ?

      Jestli fundovany, to nevim, ale v ZF programuji pres 4 roky, v Nette pres 1.5 roku – bohuzel. Nette je sileny paskvil, humus. Takze jestli nekdo chce pouzivat PHP framework, tak at jde do ZF. Sice je ZF docela moloch, ale zase se nemusi clovek starat o chybejici zakladni veci. A hlavne, existuje dokumentace i plno lidi, ktery ZF umi a poradi. U Nette je to cira zoufalost, v podstate se nic nezlepsilo od body Nette 0.9. Bohuzel existuke plno lidi i firem, ktery Nette paskvil prosazuji a chvali :(

    3. Clary

      Re: ktery framework ?

      Zdravím,
      pokud umíš python, určitě bych volil Django. Budeš moci používat jazyk, který je mocnější než PHP, jak už tu bylo zmíněno a tím pádem alespoň dle mého názoru bude čistší a přehlednější kód.

      Jinak v práci používáme ZF na své projekty používám nette. Na ZF se mi líbí hlavně to že je poměrně transparentně napsaný, program v ZF se dá dobře krokovat a pořád je nějak tak znát co se vlastně děje. Další plus bych viděl v tom, že je připravený na testování pomocí phpUnit. Jako mínus bych viděl defaultní absenci šablonovacího systému – view pak tvoří klasický špageti kód (samozřejmě je možnost použít nějaký šablonovací systém, což se třeba u nás v práci nestalo). Osobně mi také nesedí konvence CamelCaps zkombinované s podtržítky – dle mého relikt PHP4, kdy parametry tříd nebyly protected. Docela šílená je pak práce s formuláři. Navíc celý ZF je značný moloch.

      Nette je obecně magičtější, používá poměrně hodně callbacků a tak program při krokování může dost nelogicky přeskakovat. Jako hlavní výhody bych viděl Laděnku – knihovnu pro zobrazování pěkných chyb :), šablonovací systém latte, inteligentní robotLoader, díky kterému můžeš mít třídy pojmenované a zanořené v soubrové struktuře jak ti vyhovuje. I díky latte je práce s formuláři mnohem pohodlnější než v ZF. Vyhovuje mi také pojetí signálů. Nette také spoustu věcí defaultně cachuje (šablony, výstup z robotloaderu, do budoucna také routy) což může apliakci značně zyrchlit. Jako nevýhody bych viděl např. to že se při testování samotného FW nepužívají standardní nástroje jako phpUnit a vůbec absence podpory pro jednotkové testování v samotném FW, již zmiňovaná magičnost a také to že FW se z každou vydanou verzí zásadně mění což jej značně znevýhodňuje ve firemním prostředí.

      Ufff, snad jsem vyjmenoval nejpodstatnější radosti a strasti ZF a Nette. Připomínám, že se jedná o můj subjektivní pohled na věc a cílem není vyvolat flamewar. Navíc, až už se nebudu muset programováním živit, naučím se Python, Django a se sklenkou velmi staré whiskey budu vzpomíat na to jak jsem kdysi používal jazyk, jehož autoři se neshodli na konvenci, pořadí parametrů a zavedli funkce jako extract :)

          1. arron

            Re: ktery framework ?

            To pak ale nepíšete jednotkový test ale spíš test integrační ne? Resp. se to dá použít tak maximálně na jednotkový test nějaké mezi-třídy, která odděluje Vaší aplikaci od databázového engine. Jinak byste nic takového při psaní jednotkových testů neměl potřebovat :-)

            1. jos

              Re: ktery framework ?

              a když testuju metodu třídy která v konstruktoru žere nějaký data a sem takovej truhlík že práskam zdroj těch dat?

            2. Clary

              Re: ktery framework ?

              Nejsem si jistý zda zcela rozumím. Takovým typickým příkladem, který ve firmě testuji je nějaká metoda modelu, která zavolá nějaký SQL dotaz s určitými parametry, na vrácené záznamy ještě něco pověsí a celou tu sadu dat vrátí. Z pohledu jednotkového (alespoň dle mého názoru) testování pak řeším několik případů:

              1) Jestli je sada vrácených záznamů správná -tj. jestli byly na sadu dat vrácených z DB správně navěšeny ony dodatečné informace

              2) Jestli byl do DB poslán správný dotaz.

              K obojímu používám Zend_Test_DbA­dapter, který mě odstíní od reálné DB. Pak je splněna definice jednotkového testu (nepoužívá filesystem, db, síťové spojení atd., je dostatečně rychlý)

            3. arron

              Re: ktery framework ?

              @jos: definuj slovo zdroj:-) data mají vždycky nějaký zdroj, že jo. V testu vždycky nějaká data musíš připravit, jde o to jak se to udělá. Připravovat fake strukturu DB je IMHO zbytečné (a pokud se fakt připojuju k DB tak i děsně pomalé).

              @Clary: Nejsem si jistý, jestli jsem takhle na rychlo pochopil význam třídy Zend_Test_DbA­dapter, nicméně to na mě udělalo dojem, že si někam do paměti vytváří jakousi „strukturu databáze v paměti“ se kterou pak operuje. Není to zbytečné? V testu připravím data (zpravidla nějaké pole či tak něco), předám je nějakému poskytovateli, který je ve vhodnou chvíli vráti zpět skrze nějakou fake-závislost (FakeModel či něco podobného). A ano, pak testuju jestli se odeslal správný dotaz a že se mi ta data vrátila v očekávané podobě. Ale říkám, možná jsem to špatně pochopil…:-)

              1. Clary

                Re: ktery framework ?

                Přesně to dělá Zend_Test_DbAdapter – poskytuje stejné rozhraní jako má jakýkoliv Zend_Db_Adapter, ale data jsou uložena ve formě asociovaného pole pouze v zásobníku, ze kterého se pullne při každém dotazu volanéhoho nad tímto adaptérem. Někdy ani není potřeba jej nějakými daty plnit a pouze se testuje dotaz přes
                $adapter->getProfiler()->getLastQuery­Profile()->…
                Prostě takový fake objekt, který je už Zendem poskytován standardně :)

      1. alancox

        Re: ktery framework ?

        … a na jediný rozšířený jazyk, který nemá ani datový typ řetězec. :-)

        To co PHP nazývá řetězci jsou ve skutečnosti jen binární bloky – pole bajtů. Dokonce se s tím tak i pracuje.

    1. Martin Hassman

      Re: ZF1 ?

      A určitě všichni začnou hned používat dvojkovou Pokud bude zájem (na straně čtenářů i autora), není problém navázat dvojkovou verzí.

        1. hurvajs77

          Re: ZF1 ?

          To je sice pravda, ale pokud se nekdo chce seznamit se ZF nebo v nem zacit psat aplikace, je podle mne cire silenstvi psat ted neco v ZF 1.x, ikdyz bude podporovane do 2014, kdyz se rovnou muze zacit ucit ZF2. Prijde mi to jako hloupost, ted se naucit neco, co je uz ted pohrbene… :D Ale to je v podstate i PHP :-)

          1. to_je_jedno

            Re: ZF1 ?

            to, ze je php slycham uz snad 5 let… NENI a kdo vi kdy bude, urcite nejmene dalsi dekadu v pohode prezije.

            php je pro hooodne velkou mnozinu projektu good enough – nic vic nic min.

          2. Martin Hassman

            Re: ZF1 ?

            A co řada projektů, které jsou z ZF napsané? O ty se někdo musí starat, firmy na to budou ještě dlouho potřebovat (a shánět) lidi.

  3. ic

    Kde je flame?

    Nemám teď sice v plánu měnit zažitý framework, ale říkám si, že si nemůžu nechat ujít flame war v diskuzi pod článkem… a tady nic není. Jak je tohle vůbec možné? XD

    1. Honza Marek

      Re: Kde je flame?

      Musíte počkat na článek, ve kterém bude popsáno jak se se Zendem pracuje. V takhle obecném úvodu se není ani čemu zasmát.

  4. msx

    Re: Zend Framework: Úvod do frameworku

    99 % stránok využije zo samotného Zend Frameworku maximálne 30-40 %. Načo dávať obrovský nákladný vlak tam, kde stačí jeden kamión? Tým chcem povedať, že je zbytočné nahadzovať cca 20 MB framework na 99 % stránok, pretože ho nikdy plne nevyužijú. Pre mnohé stránky je vhodnejšie použiť oveľa menšie frameworky, ktoré sú zvyčajne oveľa rýchlejšie. Pri programovaní s pomocou Zend Frameworku sa často stáva, že nejaká vymoženosť tohto Frameworku robí „zbytočnú prácu“ (zbytočnú myslím to, že dá sa to spraviť aj jednoduchšie, pretože programátor nevyžaduje od tejto vymoženosti, aby všetko robila čo dokáže, ale len určité čiastky z toho čo dokáže). Potom sa to rieši tak, že príslušná knižnica sa v Zend Frameworku vypne a naprogramuje si ju programátor sám, aby to bolo rýchlejšie. Lenže potom ZF stráca svoju výhodu a tou by mala byť univerzálnosť, pretože pri ňom si takmer nič nemusí programátor doprogramovávať. Programovanie s pomocou ZF má teda síce aj silné stránky, ale vzhľadom na svoju objemnosť aj slabé stránky. Navyše je na naučenie jeden z najťažších frameworkov. Ale to je skôr subjektívny dojem, pretože nie každý by so mnou súhlasil.

    Pre jednoduché stránky by som odporučil:
    – CodeIgniter
    – CakePHP

    Pre zložitejšie:
    – Yii framework
    – Symfony

    V každom prípade ZF by som skôr neodporučil ako odporučil.

    1. Pooky

      Re: Zend Framework: Úvod do frameworku

      Zend Framework jako celek má 25mb, pokud si vybereš jenom to co potřebuješ (View Controller Form Acl Application Db Layout) tak se v pohodě vejdeš na 2.5mb

      V dnešní době kdy má hosting kapacitu 500mb na jednu stránku, nevidím důvod proč šetřit na frameworku, jsem prostě líný člověk a jsem rád, když už mám nástroje, které mohu v pohodě použít.

      1. mikiqex

        Re: Zend Framework: Úvod do frameworku

        Jenže tady nejde o velikost kódu, jako o množství příkazů, které se musí při každém požadavku načíst a vykonat. Pokud na to potřebuji celých 2.5 MB, to už je pěkných pár desítek tisíc řádků kódu! Pokud by každý řádek měl v kódu smysl, tak neřeknu, ale mnohdy je většina kódu zbytečná. Samozřejmě, pokud píšeš aplikaci pro deset souběžně pracujících uživatelů a máš na to celý server, tak není problém.

        1. j

          Re: Zend Framework: Úvod do frameworku

          Tak tak, dokud to cosi bude pouzivat 5 lidi, tak to resit netreba, ale az to budou tisicovky, tak uz se zacne projevovat kazdy zbytecny kus kodu.

          Navic obecne u frameworku sem dycky narazil na to, ze OK, neco takovyho potrebuju, jenze fous jinak.

          1. to_je_jedno

            Re: Zend Framework: Úvod do frameworku

            delam drupal, ktery osobne povazuju spis za framework nez CMS. spousta lidi o nem rika, ze to je line a pomale bumbrlik, ma tam hooky, spousty souboru, includu apod. tahne si veci ktere nepotrebuji. pokud budeme na klasickem hostingu tak maji v podstate pravdu – kazdy prekladovy string je dotaz do DB (napr.). Jeden web mi s rostouci navstevnosti zacal vytezovat server tak jsem zacal resit optimalizaci:
            1) je tam vetsina provozu anonymni? => varnish, snizeni poctu requestu na apache na cca 15%
            2) APC jako opcode, zrychleni pageload na cca 40% puvodniho (eaccelerator nebo xcache delaji +/- stejne dobrou sluzbu)
            3) memcached demon => snizeni sql provozu nekam na 20% puvodniho (z jistych specifickych duvodu nemuzu pouzit APC cache ackoliv je o dost rychlejsi)
            4) pokud tam ma byt zpracovano vyhledavani tak to frknout na solr.
            pri dnesnich cenach RAM se daji fakt delat zazraky.

            jasne je to konkretne drupal, ale stejne to podle me musi fungovat u jakehokoliv FW – opcode, memcache/mongo/co­koliv, reverzni proxy… pokud moje aplikace umi s temahle vecma mluvit tak nepotrebuju resit jestli includuju knihovnu s 5 radky nebo 500 radky. neberu v potaz extremni praseciny v kodu, ale kod napsany dle zvyklosti dobreho FW podle me pobezi rychle at z toho vyleze firemni prezentace nebo evidence objednavek. mimochodem i do toho Drupalu si v nekterych projektech casti zendu taham proste protoze mi poskytuji luxus pohodli v nekterych tech castech ktere resi (myslim ze to bylo treba oauth, nejaky soap apod.)

            1. mikiqex

              Re: Zend Framework: Úvod do frameworku

              Souhlas, pokud je ale aplikace určena na klasický webhosting, mám většinou smůlu, protože tyto vychytávky tam většinou nemají :( Chtěl jsem před nějakou dobou třeba zkusit NoSQL a zjistil jsem, že pokud to nedám na vlastní server, nemá to uplatnění.

              1. to_je_jedno

                Re: Zend Framework: Úvod do frameworku

                to je pravda, ale dneska se da solidni VPS poridit za 200,- mesicne+dph. I bez varnishe kdyz pouziju memcached + opcode APC tak mi spadl load serveru nekam na 20% puvodniho pred zapnutim tohoto. Nastesti existuji i VPS kde to neni na „sloty“ ale cpu, ram i disk se zvetsuji samostatne takze mi k relativne slabemu CPU a malo mista na disku(ktere malokdy potrebuju) poskytnou relativne levnou rychlou RAM. (maily resim zasadne na gmailu)

            2. vidya

              Re: Zend Framework: Úvod do frameworku

              asi tak nejak, neskaluje sa poctom volanych funkcii ale architekturou.

    2. BoneFlute

      Re: Zend Framework: Úvod do frameworku

      CodeIgniter neznám. Zato CakePHP ano. Můžeš mi vysvětlit v čem je lepší? Já ho nesnáším.

  5. Techi

    ZF komunita

    Jako člen české ZF komunity, který používá denně Zend Framework již 5 let, musím říct, že je trochu pozdě začínat čtenářům přibližovat ZF 1, který je z dnešního pohledu současného vývoje v PHP přeci jen trochu deprecated a tutoriálů se po netu válí hromada. Některé novinky z dvojky jsou sice backportovány do poslední verze 1.12 ale dvojková verze je skutečně překopaná od základu a přestože je venku RC2, tak se kód stále mění pod rukama, půlka testů vám failne a tak nemá zatím moc smysl psát nějaké návody či tutoriály. (Ačkoliv to jako komunita děláme, akorát z toho nejsme občas moc nadšení :)

    Pokud si chcete popovídat o ZF s komunitou, přiďte na příští ZF meetup
    http://srazy.info/prvni-zf-meetup-praha/
    http://www.zendframework.cz/

    1. dodo

      Re: ZF komunita

      suhlas, nema zmysel zacinat s tutorialom pre 1.* verziu
      co sa tyka 2.0, vidim na webe rc1, predpokladal som skor, ze v ramci rc sa budu veci ladit, nie menit pod rukami :) fail polovice testov v rc sa mi k zendu dajako nehodi, beta nepoviem …

    2. Martin Hassman

      Re: ZF komunita

      Ono je to složité, když na nový je ještě brzy a ten starý má pomalu začít mizet. Rozsáhlejších textů v češtině jsem opravdu moc nenašel, což je důvod proč začínáme tenhle seriál (paradoxně ve slovenštině, ale to je jedno).

      Na sraz bude lepší upozornit, až bude vypsán nějaký termín. Rádi zveřejníme.

      1. 5o

        Re: ZF komunita

        Denne so ZF pracujem vyhovuje presne mojim požiadavkám. Áno je pravda že sa učí tažšie keď je na to človek sám, avšak flexibilita ktorú poskytuje je geniálna.

        Jedinú nevýhodu ZF1 vidím v tom že má všade napchaté require_once, ja to riešim tak, že z frameworku vytiahnem iba požadované triedy a preženiem ich buildom do phar-u.

        Tento tutoriál ma potešil, hádam sa dozviem aj niečo nové.

  6. Erino72

    Re: Zend Framework: Úvod do frameworku

    Oplati sa zacinat s nejakym frameworkom ked mam len minimalne zaklady PHP?

    1. srigi

      Re: Zend Framework: Úvod do frameworku

      Urcite ano, ja som sa zaklady OOP naucil tak, ze som zacal experimentovat prave so Zend FW. Poznam ludi, ktori sa naucili Ruby, tak ze zacali pracovat v Railsoch.

    2. alancox

      Re: Zend Framework: Úvod do frameworku

      „I cesta dlouhá tisíc mil začíná prvním krůčkem“ – čínské přísloví

      Ničeho se neobávejte. Prostě se budete učit na frameworku i to PHP. A co? Když to bude pro někoho zábava, pojede mahoru ve znalostech rychleji než namydlený blesk.

  7. Paja

    frameworky a SQL, poznamka pro zacatecniky

    Par nazoru se ptalo, kterym frameworkem zacit.

    Setkavam se s tim, ze programatori v PHP neumi pouzivat SQL. Ulozene procedury a view jsou pro ne spanelska vesnice.
    Misto napsani procedury ci view v SQL, ktera jim data pripravi do presne podoby kterou potrebuji, zacnou vytvaret slozite objekty. Vysledkem pak je, ze misto zavolani jednoho dotazu, aplikace vyrobi desitky dotazu do databaze.

    Neni az tak slozite, naucit se SQL. Osobne pouzivam PostgreSQL s plpgsql (nejvyvinutejsi SQL zdarma). Muzete velkou cast aplikacni logiky prenest az do databaze. Odmenou vam bude rychlejsi aplikace. A i z hlediska testovani a udrzitelnosti je dobre mit rozhrani, kde z jedne strany je databaze, ktera dava data v odladitelnem a definovatelnem formatu a z druhe strany PHP framework, kde se postarate o jejich zobrazeni.

    Poznamka: Vse co se da naprogramovat v PHP, lze naprogramovat i v plpgsql. Dosel jsem az tak daleko, ze mi obcas volani dodazu do databaze vraci serializovane asociativni pole (miluji asociativni pole jak jsou udelany v PHP. V jinych jazycich to je opruz). V PHP pak staci unserializovat.

    Jeste se tu obevila v diskuzi zminka o cache. Drive jsem pouzival eaccelerator. Ten uz je ale temer nekompilovatelny v novejsich distribucich. Takze jsem zacal pouzivat APC (interface pro cache resi nezavislost). Malo kdo to pouziva takto: krome cache sriptu, umoznuji ulozit si perzistentni data. Teoreticky priklad: na kazde zobrazene strance generujete strom zbozi. Jeho vypocet zabere nejake dotazy do databaze a nejaky vypocetni cas. Pritom strom zbozi meni svou strukturu s frekvenci mesicu. Proc ho pocitat pokazde znovu, kdyz muze byt ulozen v cache.

    1. alancox

      Re: frameworky a SQL, poznamka pro zacatecniky

      Setkávám se s lidmi, kteří umějí SQL, možná i stored procedures nebo views, ale neumějí používat databáze. Neumějí navrhnout strukturu tabulek, nevědí co se děje v pozadí.

      Používat stored procedures, views, atd. je kontraproduktivní, pokud se nechcete vázat na jednu databázi. Řešit logiku a program na úrovni databáze nemusí být vždy nejlepší. Ale může.


      Ohledně frameworku. Je dobré začít s čistě psaným frameworkem, která má ideálně čisté MVC. Tedy nikoli Nette a další prasečiny.

      Pokud někdo začíná, měl by se naučit na krásu čistoty architektury frameworku a efektivnost, kterou to přináší.

      Jazyk, ve kterém je to psané není až tak podstatný, je fuk jestli PHP, Python, Ruby, Java, nebo něco jiného.

      Pokud se naučíte špatně, budete se špatně přeučovat.

      1. Michal Zahradnicek

        Re: frameworky a SQL, poznamka pro zacatecniky

        „Používat stored procedures, views, atd. je kontraproduktivní, pokud se nechcete vázat na jednu databázi.“

        Tento argument na viazanie sa na databázu som počul už mnoho krát a príde mi dosť mimo…

        Nestretol som sa ešte s tým, že by projekt „pendloval“ z jedného typu databázy na druhú. Samozrejme môže k tomu dôjsť pokial sú v úvode projektu chybne vybrané technológie. Pri koľkých projektoch sa vám to stáva?

        1. alancox

          Re: frameworky a SQL, poznamka pro zacatecniky

          Takovému SAPu se to třeba stalo.

          K migrování mezi databázemi může dojít nejenom chybně vybranými technologiemi. Ale může to být i záměr nebo podstata fungování projektu.

          Mimochodem, právě řada webových redakšních systémů má v základu možnosti pracovat na několika databázových strojů – považoval byste to za chybu? Doufám, že ne.

          Mě hlavně přijde mimo akcentovat (tedy nejsem proti tomu v rozumné míře) views a stored procedures, protože vyšší jazyky používané v projektu mají většinou lepší prostředky a lepší vývojové nástroje než mají databázové stroje.

          Jistě, že se dá v každém programovacím jazyce, který má čistě teoreticky úplnou vyjadřovací schopnost napsat cokoli. To si můžete snadno vyzkoušet na takových jazycích jako je třeba Brainfuck. Také můžete vyjádřit názor, že lze psát programy v Brainfucku namísto blbého PHP, Pyhotnu apod. – a je jenom leností lidí, že to nedělají. To je zajisté pravda, ale není to efektivní.

          Programovací prostředky většiny databázových strojů jsou poměrně dřevěné a neobratné. Programovací jazyk běžného typu je často 100 × lepším a flexibilnějším řešením.

          Kromě toho vlastní programovací jazyk má člověk pod kontrolou, móresy výrobců databázových strojů nikoli.

          Databázové stroje mají dělat to na co jsou stvořeny. Tedy pracovat s permanentními daty a zaměřit se na maximální rychlost a efektivitu. Pokud views a stored procedures přispějí k tomuto cíli (a sem tam ano), pak ok.

          Ale aplikační logika je mimo databázový stroj.

          1. Paja

            Re: frameworky a SQL, poznamka pro zacatecniky

            U view jde o to, ze spojujete nekolik tabulek. Psat nekolikanasobne joiny do mnoha mist v programu je dost neudrzitelne. Bohuzel, prilis casto narazim na projekty, ktere joiny nahrazuji postupnym volanim dotazu.

            Treba takovy trigger, je velmi mocny nastroj. Je to mimo jine takova hraz proti chybam v programu. To bez procedury v SQL neudelate.
            Pokud aplikacni logika meni data v tabulkach, pouziva transakce, tak prenesenim teto logiky do SQL nekolikrat aplikaci zrychlite. A jakykoliv sebelepsi a 100x flexibilnejsi programovaci jazyk vas nezbavi SQL dotazu. Jo, zbavi vas SQL, ale jen tak, ze ukol za vas rozlozi do 100x narocnejsiho reseni, kdy za vas vygeneruje desitky SQL dotazu. Takze misto procedury na 30 radku mate program na 20 radku, jen o rad pomalejsi.

            Mate pravdu, ze je velmi tezke zajistit prenositelnost aplikace mezi jednotlivymi SQL. Treba autoincrement u MySQL v.s. sequence u PostgreSQL se dost tezko prenasi. Ani first 10 u firebirdu vs limit 10 u ostatnich SQL neni jednoduche preklenout. Ted potrebuju vyrobit nejaky syncml server. Ktery bude pouzivat data ze stavajiciho CRM. Nasel jsem nejaky nad MySQL. Predelat ho do PostgreSQl je silenost. Protoze pouzivaji neco, co jim generuje SQL dotazy (tedy framework nad SQL). Jak by bylo krasne, kdyby pouzivali view. To bych jim mohl podstrcit virtualni tabulku, ktera by brala data ze stavajici databaze a tvarila se jako format ktery oni vyzaduji. Vcetne update rules.

            Ohledne SAPu – delal jsem v nem naposledy pred 10-ti lety. Byl nainstalovany nad Oracle. Nejvykonejsi databazi na svete pouzival jako filesystem. Snad se od te doby pohli.

            Nechtel jsem tady vyvolavat zadny flame. Jen chci rict, ze frameworky pouzivaji databaze. A to je jejich vykonovy limit.
            A ze stoji za to naucit se SQL. Pokud tedy vas projekt uklada data do databaze.

            1. alancox

              Re: frameworky a SQL, poznamka pro zacatecniky

              1) Mezi psaním SQL do programu a zasláním SQL dotazu do databáze mohou být v projektu ještě další vrstvy.

              Tedy to co se píše v programu nemusí být to co doleze do databázového stroje.

              2) Já nejsem proti view, proti triggerům, procedurám, atd.

              Stejně tak vím, že mnoho lidí neovládá ani to SQL, ani základy databázové teorie. Dokonce velké mezery v tom mají i školitelé MySQL propagovaní mimo jiné přes root/zdroják. A pokud slepý vede slepého …

              3)Není pravda že procedury a přenesení na SQL vše zrychlí. Někdy zrychlí, někdy zpomalí, někdy to zůstane stejné. Záleží na okolnostech počínaje od struktury tabulek a dalších databázových objektů, ukládaných dat, konkrétních operací, stejně jako zátěži databáze, dalších paralelních operacích na ní vykonávané, nastavení režimu databázového stroje a mnoha dalších věcech.

              4) Výkonový limit frameworků není dán výkonovým limitem databáze. Mezi frameworkem a datbází mohou být další vrstvy a framework může používat mnoho strategií na zvýšení výkonu.

              5) Stojí za to naučit se SQL, to podepisuji.

        2. Program

          Re: frameworky a SQL, poznamka pro zacatecniky

          Potřeba přejít na jinou DB je naprosto reálná. Co když původně malý systém 10x – 100x vyroste a původní DB přestane postačovat?

          1. okbob

            Re: frameworky a SQL, poznamka pro zacatecniky

            Myslíte, že si pomůžete, když přejdete na „vyšší“ databázi? Aplikace napsaná pro MySQL může být na Oracle klidně pomalejší – pokud chcete využít funkce jiné databáze, tak to obvykle znamená ještě docela dost práce – jednoduchá migrace vám spíš nepomůže. Navíc, když nějaký systém 10x-100x vyroste, tak je obyčejně tak zabastlený, že většinou stačí „uklidit“ – zopakovat optimalizaci, případně udělat databázovou optimalizaci, pokud nikdy nebyla realizovaná – a systém může docela dobře dál běžet i na původních databázích.

            Nezbytnou migraci jsem zatím viděl párkrát – a to úprk z 602 SQL serveru a Accessu – což tam už je to pochopitelné – nicméně takovou změnu aplikace provedete 1x za 10 let – 1x za průměrnou životnost aplikace – a podle mé zkušenosti se tato změna provede nikoliv tím, že se použije ORM – ale spíše, že se aplikace napíše dobře modulárně.

            Hodně ještě záleží na typu aplikací – u generických aplikací, kde se dobře kešuje a kde je minimum datově náročných operací typu mediawiki, drupal, atd nemá cenu řešit výkon na db úrovni za cenu navázání na jednu db – má smysl se soustředit na správu a využití cache. U ostatních typů aplikací – evidenční nebo procesní systémy je tomu přesně naopak – snáze se přemigruje jednoduše a čistě napsaná aplikace napsaná pro jednu db než aplikace, která se snaží být univerzální – a z toho důvodu může být zbytečně složitá.

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