BUTHRAKAUR: a co je spatny na hybridu :)? imho to je docela efektivni cesta.

TENCOKACISTROMY: to ja vim. to uz ale potom nemluvime o ciste ORM-powered reseni, ale o SP, pripadne nejakym hybridu..

BUTHRAKAUR: nic duplikovat nebudes. bude bud na strane serveru ( DB ) nebo na strane klienta ( APP ). dnesni DB servery ti umoznujou is z ty DB udelat takovy hloupy aplikacni server a tim se dostavas do klasickyho navrhu client-server.

SHAGA: mas castecne pravdu samozrejme.. zalezi ale na konkretnim pripade - myslim, ze ve vetsine pripadu to nemusi bejt zadnej zasadni performance problem.
ad zasirani aplikacni logiky - ja bych spis rek rozesirani aplikacni logiky mezi aplikaci a DB ;) pze co kdyz nepujde jenom o prosty scitani, ale bude se to pocitani ridit nejakym slozitejsim algoritmem.. co pak - zduplikujes cast aplikacni logiky do triggeru? .)

hmm..takovej peknej mrtvej klub to byl :))

JENIIK: ktera ovsem umi veci, ktere jine db neumi, a usetri mi spoustu prace :)

ale to jsme ot

JENIIK: s transakcema ORM pracovat samozrejme umej.. ale s tema eventama by to bylo asi trochu slozitejsi, kdyz o tom tak ted premejslim. ale ja nejsem zadnej NH/ORM expert, takze i ty eventy v ramci transakci jsou urcite nejak rozumne resitelny..
kazdopadne ale proc nepouzit neco jako treba:

class OdpracovanaJednotkaNaAkci{
  ...
  private Zakazka parent;
  ...
  public int MnozstviPrace{
    get{ return m; }
    set{ 
      parent.Soucty.SoucetJednotek += value - m;
      value = m;
    }
  }
  ...
}

a pouzit v transakci to muzes treba takhle:

            using (new TransactionScope())
            {
                Zakazka z = nejakazakazka;
                foreach(var j in Repository.ForOdpracovanaJednotkaNaAkci.FindAll(Where.OdpracovanaJednotkaNaAkci.Parent == z))
                {
                    j.MnozstviPrace += 10;
                    Repository.ForOdpracovanaJednotkaNaAkci.Update(j);
                }
                Repository.ForZakazka.Updata(z);
            }

TENCOKACISTROMY: no mssql sem radši netahej, to je taková db postavená trotlíkama trošku ;-)

JENIIK: tak to zalezi na konkretni DB zejo. napr. v mssql z triggeru muzes volat ulozenou proceduru, a ty maj svoje execution plany ( jestli je ma trigger z hlavy nevim, moc je nepouzivame ).

// zrejme se nam mota terminologie, ja si pod query analzerem predstavil ten okynkovej nastroj pro msssql :)

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é :-(