• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    BUTHRAKAURObject Relational Mapping :: rady, tipy, triky
     
    Object Relational Mapping

    [ Board.doc ]

    Diskuze o objektove relacnim mapovani.
    Ptejte se, treba budem vedet .)

    [ Board.quicklinks ]

    Wiki - ORM na wikipedii
    Castle ActiveRecord
    NHibernate Query Analyzer
    NHibernate Query Generator
     
     

    No flames | Check homepage

     
    rozbalit záhlaví
    JENIIK
    JENIIK --- ---
    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...
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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?
    JENIIK
    JENIIK --- ---
    TENCOKACISTROMY: update něco=něco+něco_jiného where cosi=cosi_jiného

    ???
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    JENIIK: znas lepsi reseni jak updatovat data z UI do DB?
    JENIIK
    JENIIK --- ---
    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?
    SHAGA
    SHAGA --- ---
    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í?
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    BUTHRAKAUR: a co je spatny na hybridu :)? imho to je docela efektivni cesta.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    TENCOKACISTROMY: to ja vim. to uz ale potom nemluvime o ciste ORM-powered reseni, ale o SP, pripadne nejakym hybridu..
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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.
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    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? .)
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    hmm..takovej peknej mrtvej klub to byl :))
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    JENIIK: ktera ovsem umi veci, ktere jine db neumi, a usetri mi spoustu prace :)

    ale to jsme ot
    BUTHRAKAUR
    BUTHRAKAUR --- ---
    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);
                }
    

    JENIIK
    JENIIK --- ---
    TENCOKACISTROMY: no mssql sem radši netahej, to je taková db postavená trotlíkama trošku ;-)
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    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 :)
    JENIIK
    JENIIK --- ---
    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.
    TENCOKACISTROMY
    TENCOKACISTROMY --- ---
    JENIIK: co konkretne nejprojde query analyzerem?
    JENIIK
    JENIIK --- ---
    SHAGA: no řádově nevím, ale minimálně to neprojde query analyzerem...
    SHAGA
    SHAGA --- ---
    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.
    SHAGA
    SHAGA --- ---
    BUTHRAKAUR: Protože trigger je řádově rychlejší. Ostatně od takovýchle věcí byly triggery vynalezené.
    JENIIK
    JENIIK --- ---
    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.
    Kliknutím sem můžete změnit nastavení reklam