JENIIK: jj, to taky pouzivame. ale uklada se to spolecne s tim jednim zaznamem v transakci.

model: uzivatel na polozce dokladu zmeni produkt. po zmene hodnoty v zaznamu polozky se nactou urcite vlastnosti produktu ( podle nejakeho pravidla ) a vytvori se podle nich vlastnosti polozky. pri ukladani zaznamu se pak ulozi do svazane tabulky s vlastnostmi polozky nove zaznamy.

takze vysledek je nejaky takovyto (zjednodusene):

UPDATE tblDokladyPolozkaProdukt SET IDProdukt = 'aeb32810-04f7-4516-80fa-8f63d783c885'
DELETE tblDokladyPolozkaVlastnost WHERE IDPolozka = '91a41310-58ea-49b1-be5d-64270f11abbe'
INSERT INTO tblDokladyPolozkyVlastnist ( VlastnostID, IDPolozka, IDDruhVlastnosti, Vlastnosti ) VALUES ( ............. )

Takhle se to normalne dela, pokud mas scenar s "odpojenymi daty". Kdyz to spravne implementujes tak, mas jistotu ze se ti bud ulozi vsechno nebo nic.

TENCOKACISTROMY: no to jo, ale to, co jsem viděl dole mělo simulovat mlj trigger a to dost nešťastně. Totiž změnou jednoho záznamu můžeš změnit X záznamů ve statistických tabulkách...

JENIIK: nerozumime si.
Uzivatel v UI vidi tabulku s X zaznamy. z tech X zanamu jich Y upravi, coz spusti dalsich Z uprav jinde. kazda uprava je "originalni" ve smyslu ze kazdy z tech upravovanych zaznamu ma zmeneny ruzny sloupce a v nich ruzne hodnoty.

jak to udelat jinak nez nekolik update prikazu do sql?

TENCOKACISTROMY: update něco=něco+něco_jiného where cosi=cosi_jiného

???

JENIIK: znas lepsi reseni jak updatovat data z UI do DB?

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.