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 :
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.
Java neni spatny jazyk ale nema zadnou podporu pro paralelismus a zamykaniSi 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?
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 nemateOoops, 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 myslitePokial 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 nicsuhlas.
a neurobite s tym obvykle nicnesuhlas. 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.
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.