BUTHRAKAUR: Ja to takhle delam uz leta a jsem s tim tak nejak v pohode. Jediny neprijemny je verzovani databaze (ale to se musi resit tak jako tak), a na to mam uz nastroje.

TENCOKACISTROMY: efektivni z hlediska vykonu urcite - ja psal "efektivni na spravu" :) Ale to je vec nazoru samozrejme..

TENCOKACISTROMY: tak samozrejme, stejnak jako u souteze o 100x Nokia Lumia, jak nedavno skoncila.

NECROMAN: Levnej nakup aplikaci :).

Súťažte od 23.7. do 31.10. o desiatky smartfónov Nokia Lumia 800, Windows 8 tabletov, herných konzol Xbox 360, Visual Studio 2012 a množstvo ďalších cien!
Homepage - ADAM.sk
http://zive.sk/winappchallenge

Zajimavy objev - ve "finally" vetvi nelze pouzivat return... clovek se porad uci :)

BUTHRAKAUR: Naopak, efektivni to je naramne. Je to jako by jsi delal samostatnou vrstvu/knihovnu, ktera ma nejaky rozhrani. Dotycny rozhrani pak pouzivas. Pritom ty SQL objekty pises v necem, co je k tomu urceny a muzes vyuzivat vsechny vychytavky dotycny DB. Nejsi pak omezenej nejakym ORM ani to nemusis z pameti psat do nejakyho neudrzovatelnyho stringu.

EDISN: velmi prekvapive najdes trial na webu mathworksu. btw dost zvlastni otazka na C# diskuzi

Zdravím, nemáte někdo zkušební verzi Matlabu, nebo kde se dá funkční verze stáhnout? Díky

TENCOKACISTROMY: tak s tema view apod potom asi jo - s tim jsem nepocital, pze mi to nepripada z hlediska vyvoje efektivni na spravu a tak (ale to je OT) :) To pak jsou ty LINQ dotazy vazne primitivni a neni v tom asi problem - myslel jsem pripady, kdy se klasicky joinuje, nejaky agregace, subselecty a tak. Tam pak na linq a optimalni dotazy moc neverim..

BUTHRAKAUR: Tak ja stejne pouzivam view/tabulkovy-funkce/ulozeny-procedury a nasledne pak z selectuju z nich. Takze v tom LINQovym dotazu mam vetsinou jednoduchou WHERE podminku a nejaky ten ORDER BY.

Na nezavislost mezi aplikaci a databazi neverim, pokud zalezi na vykonnosti a DB se nepouziva jen jako "takovy-lepsi-soubor".

TENCOKACISTROMY: akorat mas pak jeste o neco mensi kontrolu nad vygenerovanym dotazem nez u vic low level dotazovacich nastroju IMO.. = SELECT N+1 apod radosti

tak nas MAGIC UNICORN je open-source :)

Entity Framework Magic Unicorn (and much more!) is now open source with take backs - Scott Hanselman
http://www.hanselman.com/blog/EntityFrameworkMagicUnicornAndMuchMoreIsNowOpenSourceWithTakeBacks.aspx

Entity Framework
http://entityframework.codeplex.com/

BUTHRAKAUR: dík za tip

BUTHRAKAUR: LINQ mi naopak pripada jako vybornej napad na dotazovani do DB. ze ten AST umi bejt komplikovanej je sice fakt, nicmene pokud se clovek prehoupne pres pocatecni zmateni, tak mi to prijde celkem ok. Navic uz jednou mi zachranil kuzi, kdy jsem diky nemu mohl dost snadno prejit z SqlCE na Db4O (jeste na starickym CF :)).

ESY: špatný klub, promiňte.

jo a ORM jsou nutny zlo, ktery zpusobili zli RDBMS marketingovy specialisti v boji proti objektovym/nerelacnim puristum! ;D

SAJAGI: v NH si muzes nadefinovat dodatecny DB funkce (v dialect nebo primo v dotazu pomoci Projections.SqlFunction()) - ty pak jdou pouzivat v criteria API/QueryOver, ale v NH Linq pochybuju.. Stejne je Linq na DB dotazovani prilis abstraktni zlo a podle tvy zminky o linq DB nahrazku v testech to trochu zavani :)

SAJAGI: No, to je takovej workaround. Vykonu to zrovan moc nepomuze.

P.S. me ORM nebavi, ale s nim je to tezky a bez nej peklo :)))

TENCOKACISTROMY: No, já v nhibernate nedělám zase tak dlouho, a google mi moc nepomohl. Víceméně podobnou záležitost (vyhledávání podle hashe) nakonec řešili všichni tím, že buď to v DB i v kódu převedli do stringu, nebo počítali hash v databázi (což pro mě není moc možnost, protože počítám hashe až z několika MB).

(mě to baví :D)