BUTHRAKAUR: tohle myslíš vážně? poslat na DB stroj hromadu updatů postupně za sebou? To mi nepřijde optimalizované. Je to hezké pro programátora, server se na to bude tvářit trošku jinak ;-)

nebo se snad z toho for each vygeneruje jeden dotaz?

BUTHRAKAUR: Pochopitelně hranice mezi tím co je aplikační logika a co logika ukládání dat je mlhavá. Někde vést řez musíš a umění vedení tohoto řezu je také to, za co tě platěj. Ostatně já nemám pojem "business logika" rád, on vytváří dojem, že je snad součást aplikace která není business logikou. Přitom to, zda řádek v tabulce bude při splnění nějaké podmínky zelený či červený je čistě view, ale není to i business? A podobně i směrem k datům: je požadavek na rychlé redundantní tabulky v nenormalizovaném tvaru business, nebo není?

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?