TENCOKACISTROMY: Možná jsem se nepřesně vyjádřil, ale jde o to, že trigger je zkompilován tak, aby minimálně zatěžoval server, tím pádem se neřeší syntaktická analýza dotazu, neřeší se překlad jmen na okazatele na objekty a podobně.

Query analyzer se může a nemusí použít, postgres ho tuším nepoužívá a triggery překompilovává jen po analyze.

JENIIK: co konkretne nejprojde query analyzerem?

SHAGA: no řádově nevím, ale minimálně to neprojde query analyzerem...

BUTHRAKAUR: A protože si tím nezasíráš aplikační vrstvu a necháš DB vrstvu dělat to, co dělat umí dobře - starat se o data.

BUTHRAKAUR: Protože trigger je řádově rychlejší. Ostatně od takovýchle věcí byly triggery vynalezené.

BUTHRAKAUR: zajistí mi to atomicitu zpracování? Že to může vést k redundanci kódu je pak asi jasné... Přecijen ta data se mění s každým zápisem do tabulky (lépe řečeno při každé změně property dané třídy, bylo-li by mapováno) a pokud se stane nějaká hromadná změna, nebudu to chtít řešit tak, že si vysomruju miliardu tříd a na všech zavolám změnu a save, ale budu to chtít v jedné transakci, že...

Možná uvažuju blbě a možná, že tohle už něco nějak řeší, nevim.

BUTHRAKAUR: btw v tom hibernatu me dost desi jak se to tvari pak na trebas refaktoring toho objektoveho modelu? kor kdyz clovek ma nejake fixtures?

BUTHRAKAUR: no v iBatisu muzes udelat explicitni mapovani sloupec->property, ale muzes to ridit konvenci. tj proste mas trebas select:

SELECT country_id AS id, country
FROM countries;

a mas objekt Country s propertou id (kvuli tomu tam mam to AS) a country a na ty se ti to (dle konvence) namapuje. tedy nemusis mit nic nez ten select, mapovani si to pokusi udelat samo. ale je fakt, ze timhle ztratis jakousi silnejsi typovou kontrolu - protoze explicitni mapovani ti to checkne pri startu ze sedi, ale tohle lehne afaik az pri pokusu o namapovani (za behu). navic muzes v tom selectu udelat veskere rekneme skladani N:M relaci a mit pod kontrolou napriklad Query optimizer - ale to je spis jakasi tresnicka.

JENIIK: a proc nemuzes misto triggeru pouzivat eventy v tridach?

LITTLELI: holt to (N)H musi umet clovek spravne pouzivat (jako ostatne vsechno) a dobre tu aplikaci nadesignovat. s tim lazy loadingem se vazne da udelat dost kixu..
ad anotace - to je jenom jeden zpusob - muzes mit nadefinovany mapovani i externe, pokud ti to ve zdrojacich prekazi. iBatis to ma tusim podobne, ne? ono nekde to mapovani definovany bejt musi... i kdyz asi by se dal napsat mechanismus, kterej by ti primo z trid vygeneroval mapovani + DB strukturu, ale to by asi nebylo uplne to pravy :)

BUTHRAKAUR: no a ta pomocná entita je pak co? jen soubor sql. Ty pomocná data stejně musíš sbírat triggerama (dobře, nemusíš, pokud nechceš používat transakce v sql, ale... ;-)) takže aplikační logiku máš stejně i v db. Ona pomocná entita je ta moje helper class. Takže objekt zakázky pak používáš k čemu?

Není to ani čisté, ani intuitivní, ani automatické, ani jednoduché... Nějak v tom nic nevidím...

Prostě data se sice tváří jako objekty, ale v momentě, kdy s nima začneš pracovat relačně, tak se ti víc hodí relační přístup. V momentě, kdy přestaneš pracovat fakt s jednotlivými objekty, dostaneš se do situace, kdy začneš celý objektový koncept ojebkávat a to je přesně to, co se mi nelíbí.

Objektový přístup k věci mám rád, ale spíš směrem k funkcionalitě, než k datům. Sám jsem kdysi u EJB jásal, jak je to super věc, dokud jsem nezjistil, že je to nedomyšlené :-(

JENIIK: a tyhle pomocny struktury jsou pro ORM nejakej problem? to zadani se zakazkama jsem asi uplne nepochopil, ale pocitam, ze ke kazdy zakazce chces mit nejaky soucty (soucet odprac jednotek), prumery, odhady atd.. jestli jsem to dobre pochopil, tak ty mas nejakou pomocnou tabulku, kde udrzujes tyhle soucty atd - je to tak? proc by potom v pripade ORM nemohlo bejt neco jako trida StatistikaZakazky, ktera by pracovala nad nejakou takovou podobnou tabulkou a starala se o tyhle veci?

ale pocitam, ze jsem asi spis neco zasadniho ze zadani spatne pochopil :)

BUTHRAKAUR: mne desi ty veci jako je lazy loading nebo jak se tomu rika a caching a objektova identita. obcas mi napisou kamaradi kteri maji nekde hibernate a dost knouraj. pro mne to bylo docela slozite, nechapu trebas proc bych mel anotovat nejaky property na entitach a urcovat relace na objektovym modelu kdyz to de fakto nedava smysl. ale z druhe strany trebas skladat dotazy z retezcu pro JDBC, klidne i ve Springu je dost oskliva vec :( proto jsem zacal s tim iBatisem.

BUTHRAKAUR: aleale, jako o reportingu moc nevím, živil jsem se tím naplno jen asi rok, ale OLAP není řešení přeci. Existuje spousta důvodů proč musíš někdy použít online data a tam se pak bez redundance a různých statistických sběrů dat v momentě updatu neobejdeš. Jak to pak naládovat do objektů... Nevim. Obecně si myslím, že lidi OLAP dost přeceňujou...

Vem si jako příklad ten můj výpis zakázek, každá má součet odpracovaných jednotek na akcích, datum poslední vydané fa, přijaté fa, objemy obojí fakturace, odhadovanou ziskovost... Tyhle data bys v čistém modelu získával z cca 10 - 15 objektů. A ani čistě relační řešení ti nepomůže, protože výkonově nebude stačit, takže potřebuješ prostě pomocné struktury, kde máš tyhle data pořád velmi rychle k dispozici. Tohle ti obecný framework nezajistí, nehledě na to, že ty data nepoužíváš jen na jednom místě atd atp. Když do toho vleze ještě institut "podzakázky" a shlukování těchhle podzakázek, tak už se z toho zjančíš úplně.

A to je prosím stupidní výpis zakázek, jednoduché zadání, nic složitého.

Možná existuje řešení, které to umí nějak elegantně celé vyřešit, ale mě z toho pořád plyne prostě nějaká hepler class a sql psané pro každou aplikaci a výpis zvlášť, protože prostě jinak to kvůli rychlosti nejde.

JENIIK: zalezi, o jakym typu a rosahlosti aplikace mluvis - ja se pohybuju spis kolem mensich veci.. ale porad si myslim, ze pokud mapper pouzijes spravne a nezabrednes do nejakejch prasaren, tak se vykon nemusi lisit od klasickyho pristupu + navic ziskas vyssi efektivitu pri kodovani.

a s tim reportingem - pokud to s reportingem nekdo mysli vazne, tak stejne skonci u OLAP kostek apod, kam se to stejne pumpuje. a je ve vysledku uplne jedno, jestli se to pumpuje z OR-mapovanejch nebo klasickejch tabulek. bezi mi takhle nad jednou NHibernate aplikaci reporting v Oracle BI a nejak nepozoruju problemy...

TENCOKACISTROMY: každý to použije nějak ohnuté, proto se ptám k čemu to máte. ;-)

JENIIK: nam to slouzi k tomu, ze v aplikacni casti mame vsechno silne typove. tim ziskavame kontrolu nad tim, ze do datetime "sloupecku" necpeme string apod. navic, se silne typovym pristupem ti IDE muze dost ulehcit praci ( vsechny mozny doplnovani, a dohledavani souvislosti, apod ... ).

krome toho nad tim mam udelany SQL-like API pro dotazy na data, ktery je taky silne typovy (+ upraveny tak, aby se z UI lehce prenasely filtracni podminky ).

ale netvrdim, ze to je nejlepsi mozny zpusob, ani ze to je vhodne pouzit ve vsech pripadech.

TENCOKACISTROMY: otázkou pak zůstává k čemu je člověku pak ten samotný datový objekt. Pokud teda neslouží k abstrakci od SQL, což je stejně asi pitomost, protože ty další objekty mají custom SQL v sobě - předpokládám.

JENIIK: tak to mame udelany my. existuje relacni model, ktery je preklopeny do trid v aplikaci. a v aplikaci pak jsou tridy, ktere zarizuji tu praci s datama ( vytvareni novych, kontrola hodnot & souvislosti, automaticky dopocitavani hodnoty & zaznamu, apod... )

objekt reprezentujici datovy zaznam pak ma jen data & par metadat a priznaku typu "titulek atributu (sloupce)", stav zaznamu ( novy, modifikovany, smazany, ... ) a objekty okolo pak zaridi ze se spravne prenese do databaze.

jsem s timhle pristupem docela spokojenej.

TENCOKACISTROMY: no to je to o čem mluvím, jestli není nakonec lepší dívat se na data relačně a udělat si sadu objektů, která ti maximálně usnadní přístup k datům, odstraní redundanci atp...