Hlavní navigace

Vlákno názorů k článku Entity beans v JBoss a relace od backup - vidim to jenom ja, nebo ma jeste nekdo...

  • Článek je starý, nové názory již nelze přidávat.
  • 3. 12. 2008 11:46

    backup (neregistrovaný)
    vidim to jenom ja, nebo ma jeste nekdo jiny take pocit, ze tudy cesta nevede. Pripada mi to vsechno tak zbytecne komplikovane, nafoukle, vhodne pro skolici instituce. Deleat s tim levne software pro mensi zakazniky - jde to?
  • 3. 12. 2008 12:39

    Petr (neregistrovaný)
    Jasne, rekl bych, ze vetsina Java aplikaci a java programatoru pouziva toto nebo primo Hibernate, takze ano.
  • 3. 12. 2008 13:49

    libor (neregistrovaný)
    Většina aplikací v Javě, které se dnes píšou, využívají objektově relačního mapování. Nevím co konkrétně vám připadá nafouklé a komplikované, mapování pomocí anotací (nebo xml) se provede jednou na začátku a ostatní kód je pak jednodušší, přehlednější a lépe udržovatelný než 'neobjektový' přístup při použití přímo JDBC API.
  • 3. 12. 2008 14:28

    ivan (neregistrovaný)
    JJ, resit problemy s takovymi systemy je fakt lahudka. Obvikle to vypada tak, ze mi nekdo zavola a ma zadani: Nevime co vsechno jsme zmenili, nevime jake pouzivame indexy, nevime kteri uzivatele ted pouzivaji aplikaci, nevime co uzivatele v aplikaci delaji, nevime jake SQL dotazy nase aplikace provadi, nevime co vsechno zamykame a v jakem poradi, nevime kolik mame aktivnich sessions do DB, ale chyba je urcite na strane databaze a musite to rychle spravit. Takovehle technologie slibuji programatorum, ze nepotrebuji nic vedet o databazich. Bohuzel je to jen slib, ktery se neda splnit. Tohle se hodi jen pro male systemy s max. nekolika desitkami uzivateli.
  • 3. 12. 2008 15:07

    Vladimir Kralik

    ale az potom ako tie aplikacie zoptimalizuje niekto kto ma prehlad o zlozitosti algoritmov a datovych strukturach, a najma vie co sa za jednoriadkovymi prikazmi deje.

    Klasicky pripada od nasich programatorov ( mapovanie Hibernate ).

    if ( partner.getObjednavky().size() > 0 ) ...
    

    V skutocnosti sa vykona toto :

    1. select * from objednavky where partner_id = ?
    2. java si vsetko poslusne natiahne do pamate ( List )
    3. a spocita pocet prvkov v danom zozname

  • 3. 12. 2008 15:17

    Cartman (neregistrovaný)
    Prevratna novinka ! Programator ktery nevi co dela zpusobil kolaps systemu. Vice se dozvite na TN.cz.
  • 3. 12. 2008 15:25

    Palo (neregistrovaný)
    Prave preto uprednostnujem fyzicky oddelenu entitnu/servisnu vrstvu. Tam si to jednak dokazem lepsie postrazit (menej programatorov ale skusenejsich) na webe nech sa chlapci hraju s farbami a okrajmi.
    Za druhe ale predpokladam ze asi potom nieco s tym zoznamom robil takze to mozno bolo aj optimalne. Za dalsie uz pri navrhu nerobit relacie obojsmerne a ked tak opacne z objednavky na partnera. Potom im to uz dojde ze musia pouzit nejaku sluzbu ktora sa da mozno optimalizovat.
    Ale inac pekny bordel.
  • 3. 12. 2008 15:30

    Palo (neregistrovaný)
    Inac napr. s Hibernatom je uplne najvtipnejsie ked vam niekto prepise (a nespravne) metody ako equals a hashCode. To je az ten spravny bordel a zle sa to hlada.
  • 3. 12. 2008 15:38

    Vladimir Kralik
    Prave preto uprednostnujem fyzicky oddelenu entitnu/servisnu vrstvu

    Pridavanie dalsich a dalsich vrstiev iba zneprehladnuje aplikaciu. Ja som netvrdim, ze ER mapovanie (Hibernate) je zle. Ja sa stazujem, na nevedomost programatorov, ktori si o sebe vela myslia ale v skutocnosti toho malo vedia.

    Za druhe ale predpokladam ze asi potom nieco s tym zoznamom robil takze to mozno bolo aj optimalne

    Ani nahodou, nemaju ziadne zabrany, bez problemov si napchaju do pamate sto tisic zaznamov, len aby zistili ci existuje nejaky.

    Inak Hibernate poskytuje atribut, ktory umozni namiesto nacitania vsetkych entit do pamate urobit iba "select count(*) from objednacky where partner_id =?".

    Za dalsie uz pri navrhu nerobit relacie obojsmerne

    Zly napad, nezadefinovanim obojsmernej relacie v entitnom modeli si znemoznim vytvarat dotazy cez HQL ( Hibernate Query Language ).

    Na tento problem mam zatial jedine riesenie : Dat vyvojarom tak velku DB, aby taketo hluposti nemohli prehliadnut a neustale robit reviziu kodu.

  • 3. 12. 2008 16:05

    ivan (neregistrovaný)
    To je presne ono. Koho dneska zajima jaky je rozdil mezi "select * from" a select "count(1) from"?
    Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani(narozdil treba od archaickeho pl/sql) Tyhle programy jsou vyvijene jako jedno-uzivatelske a podle toho taky funguji. Ze zdrojaku takovehle aplikace se da tezko odvodit co se bude dit v databazi a jakym zpusobem potom databaze ovlivni ostatni uzivatele.
  • 3. 12. 2008 16:40

    Palo (neregistrovaný)
    Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykani
    Si robis srandu. Nepoznam jazyk ktory obsahuje tolko moznosti pre zamykanie a paralelizmus ako ma Java. Od low level java.util.concurrent.atomic az po high level struktury java.util.concurrent a java.util.concurrent.lock. Tam je uplne vsetko. Nie som taky dobry v PL/SQL, ako si tam zalozim dalsi thread?
  • 3. 12. 2008 17:56

    Vladimir Kralik
    Mam ten dojem, ze miesate hrusky (Ivan : transakcie,select for update,isolation level) a jablka (Palo : thread-y, semafory ).

    Fakt je vsak ten, ze velmi vela sucasnych Java programerov nema potuchy o tychto pojmoch ( ani o jednom vyzsie uvedenom ) a potom ten kod aj tak vyzera :-(.
  • 3. 12. 2008 22:01

    Palo (neregistrovaný)
    A to si si z coho vylozil, z kariet? Ivan nehovori nikde o transakciach ani o isolation level. Ja ti poviem ze je vela programatorov ktory neovladaju ani Javu a to myslim veci ako genericke typy ich pouzivanie, nerozumeju zakladom objektovej dekompozicie, patternom, ktore v pl/sql pre istotu ani nemate a nemozte ich urobit.
    Isteze kazdy by rad robil v teame samych profesionalov a nemusel sa pozerat ako niektori programatori koduju v style ktoremu ja hovorim "coding by accident". Najlepsie je napisat nazov nejakej suvisiacej premennej, buchnut tam bodku a stlacit CTRL+medzera. Potom si vyberu co sa tam najviac hodi, postup opakuju kym nie su spojny a idu dalej.
    Ja robim vela z architekturami systemov, isteze musis mat v time niekoho kto sa v tom vyzna to ale neznamena ze KAZDY to musi vediet. Mas ludi ktory sa vyznaju vo frontendoch, Script enginoch, rule enginoch, BPML, SOA. Praca s DB nie je zas az taky science ako si myslite. Je to dolezite ale su to obycajne kazdodenne problemy projektu.
    Mate programatorov ktory programuju frameworky, mapovanie do DB a niektori citaju specifikaciu a snazia sa to cele najako pochopit a pozliepat dokopy. To su problemy velkych projektov. Male projekty dajte robit radsej niekomu kto sa v tom naozaj vyzna.
    Ja som pracoval na projekte kde sme aj v dev prostredi zriadovali stlpce v tabulkach cez DB specialistu ktoremu sme posielali dobre ze nie rovno SQL ktore sme si nemali ani kde vyskusat a ten imbecil bol schopny po dvoch dnoch vam to vratit ze tam chyba ciarka. Naco je taky DB specialista.
    Nejako som sa rozpisal len som chcel povedat ze kazdy nieco vie a niektori nevedia nic a neurobite s tym obvykle nic lebo s nimi musite zit na projekte a v tom je to umenie vychadzat s ludmi.
  • 4. 12. 2008 10:54

    Vladimir Kralik
    A to si si z coho vylozil, z kariet? Ivan nehovori nikde o transakciach ani o isolation level.

    Pretoze to je klasicky pripad pohladu DB-specialistov na problemy paralelizmu. Je to proste ich uhol pohladu.

    patternom, ktore v pl/sql pre istotu ani nemate

    Ooops, pattern je navrhovy vzor, a ako taky moze byt pouzity v lubovolnom programovacom jazyku. Neprogramujem v pl/sql, ale ani si nedovolim nan nadavat. Rovnako nechvalim Javu do nebies. Bud niekto programovat vie, a potom je jedno v akom programovacom jazyku robi, alebo programovat nevie a potom je jedno ake programovacie jazyky ovlada.

    Praca s DB nie je zas az taky science ako si myslite

    Pokial vsetko funguje, a DB sa vojde do pamate, tak nie je problem. V momente ak DB narastie cez 1TB a pripajaju sa stovky pouzivatelov, tak je sakra dolezite ako je to napisane.

    kazdy nieco vie a niektori nevedia nic

    suhlas.

    a neurobite s tym obvykle nic

    nesuhlas. Je treba robit osvetu, skolenia, reviziu kodu, unit-testy, integracne testy. A pokial sa takyto "programator" nechce/nevie naucit ako to ma robit, tak sa s nim rozlucim.

  • 4. 12. 2008 15:59

    Palo (neregistrovaný)
    Ooops, pattern je navrhovy vzor, a ako taky moze byt pouzity v lubovolnom programovacom jazyku.
    Nie celkom, ak ti chybaju zakladne mechanizmy ako polyformizmus alebo riadenie threadov (ako napr v PL/SQL) tak ten pattern neurobis. Existuju objektove patterny ktore v struktorovanom jazyku neurobis.
    Pokial vsetko funguje, a DB sa vojde do pamate, tak nie je problem. V momente ak DB narastie cez 1TB a pripajaju sa stovky pouzivatelov, tak je sakra dolezite ako je to napisane.
    Teraz ma tu vsetci zabijete ale my sme raz mali vykonostny problem na aplikacii a bolo lacnejsie prikupit server ako to optimalizovat aj ked som bol proti. Cost efektivita nepusti. Samozrejme ze je dolezite ako je to napisane ale pomocou roznych nastrojov sa da zistit kde ti to koliduje alebo dlho trva. Tu sa da v Java pekne vyuzitelne AOP a na cas si nainjectovat kod nejakym performance aspectom. Ale inac suhlas.
    nesuhlas. Je treba robit osvetu, skolenia, reviziu kodu, unit-testy, integracne testy.
    Pokial to robis v domovskej firme tak OK. Zaujimavejsie je ked sa zide particka najomnych zoldnierov s 5tich roznych firiem plus domaci stuff a zacne sa robit 1.5 rocny projekt. Skus o niekom povedat ze je blbec a potrebuje skolenie. Zacnes byt ako nekooperujuci prvok vytlacany nech si ako chces dobry. Na takychto projektoch rozhoduje kto si a koho mas za sebou nie co vies. A k tomu politicka pretlacania jednotlivych firiem. Proste lahodka.
  • 4. 12. 2008 10:32

    ivan (neregistrovaný)
    Jo presne tohle jsem myslel. Samozrejme ze vim ze java ma vlakna, zamky a vubec vsechno co takovy jazyk ma mit. Problem je v tom, ze si mnoho programatoru neuvedomuje, ze tim ze se pripoji k nejake databazi ovlivni praci tisicu uzivatelu, kteri pracuji s tou samou aplikaci. Kdyz v jave napisete "a.b=1;"
    tak z toho nemate jak odvodit co se bude dit v databazi a hlavne nevite kolika uzivatelum znemoznite praci. Kdyz to porovnam se zastaralou, nemoderni architekturou klient-server (treba Oracle Forms)
    tak muzu treba zjistit ze: "Uzivatel Vomacka, prihlaseny z PC JVOM pouziva modul aplikace XY, ma zamcenou radku v tabulce ABC a tim blokuje uzivatele Ruzickovu v modulu YZ". A cele mi to zabere asi 20 minut. Kdyz neco podobneho resim na aplikaci bezici na websphere tak to mam minimalne na tyden. To je pak mnohem jednodussi kazdou pulnoc spustit "killall java". Casto se stane, ze se chyba v aplikaci projevi v databazi. Kdyz ale tu databazi abstrahujete a nemate jasnou predstavu o tom co po te databazi vlastne chcete, tak se ty chyby velice tezko resi.