> On Mon, 11 Dec 2006 23:41:13 +0100, Oto 'tapik' Buchta <[EMAIL PROTECTED]> > wrote: > > On Monday 11 December 2006 14:56, Jaroslav Kortus wrote: > >> > Dejte vedet, k cemu to vlastne potrebujete... > >> > >> Ja se s tebou hadat nechci :) mam na to vlastne stejny nazor jako ty. > >> Nevim, jestli je objektova db rychlejsi, ale urcite se zatez rozdeli, ne, > >> ze ve vysledku bude mensi. > > > > No, mozna jsem trochu mimo misu, ale co myslis pod pojmem rozdeleni zateze? > > Tento pojem u desktopove aplikace mi jaksi neni jasny. To jako pocitas s > > dual-core procesory? Ale na to nepotrebujes objektovou databazi. Takze, > > prosim, definuj pojem rozdeleni zateze, nejak mi neni jasne, CO se vlastne > > deli a mezi KYM. > > Mluvili jsme o OR mapovani vs. objektove db, nebo jsem to tak aspon pochopil. > U OR mapvani se provadi prevod mezi rel. db a objektama za behu (coz neco > stoji > a neni> to bezpodminecne nutny. K datum se preci da pristupovat i primo > pomoci sql > dotazu, cimz bys onu rezii na OR mapovani usetril, jenze zase pro nejakeho > programatora to muze byt nepohodlne). Pokud pouzijes objektovou DB, muzes > vyuzit> objektove architektury aniz bys musel neco mapovat.. O tom, co bude > ve vysledku > rychleji pracovat by se dalo polemizovat, objektove db ale neexistuji ciste > proto, abys> mel applikaci nejrychlejsi, ale abys mohl k datum pristupovat > pomoci > objektovych> principu - tj, abys mohl applikaci vyvijet plnne objektove - na > vsech vrstvach > a nemusel mapovat - tedy jako jakasi analogie se serializovanymi objekty. > Co jsem mel moznost videt a slyset, nasazeni objektovych DB neni zrovna na > vzestupu> a asi ani jen tak brzo nebude. Jestli nekdo tento nazor nesdili, > podelte se.. > Takze zatez se vlastne nedeli, ale jde o to, ze usetris mapovani na strane > applikace> ale zaplatis pomalejsi DB. Jeste tu je moznost, ze autor myslel > offline > desktopovou> applikaci, kde pobezi DB i aplikace na jednom stroji.. no, pak > je skutecne > nejake> deleni vykonostni zateze mozne jedine na bazi vicejadrovych nebo > paralelnich > stroju. > Ahoj, Pochybuju ze myslel deleni az na tak hluboke urovni, jako je scheduling u procesoru :). Spis myslel, ze se rozdeli aplikace na vice kusu. Temi kusy myslim MVC, coz pri vytvareni DAO se tam muze vrazit jeste "jedna vrstva" a tou by byl onen ORM Framework. ORM Framework tady hraje ulohu "database" ikdyz on sam databazi neni...
Spis by me zajimalo, jestli se vyplati delat DAO kdyz se pouzije nejaky ORM Framework. Oni totiz v sobe DAO uz maji, a je to takovy zacarovany parez , DAO pro DAO :). No jo, ale co kdyz chceme udelat opravdu universalni pristup k databazi z aplikace? To tam to DAO stejne vrazit musime, protoze se muze stat, ze nebudeme chtit pouzivat Hibernate ale jiny ORM. :) to uz by se nemelo jmenovat DAO, ale ORMAO :) Nebo hold nepouzit DAO pro pristup k ORM frameworkum (databazi), ale jiny DP pro zajisteni persistence objektu, napriklad Wrapper. U toho uz bych zadny problem nevidel. Nejake napady nebo myslenky ohledne tohoto? Ondras.
