Staňte se programátorem: Kouzelný LINQ

Diskuze čtenářů k článku

bigsam72  |  13. 08. 2009 07:54  |  Microsoft Windows XP Firefox 3.5.2

Jsem ze stary skoly ( Assembler/C/C++) ale vzdycky kdyz vidim jaky zverstva jsou schopny nekteri vytvorit a nazvat to vyvojem/pokrokem. Problem vidim v tom ze vetsina techto technologii funguje "na skolnich prikladech" v praxi to vede jenom k nocnim muram provozu. Jeden priklad z posledni doby s kterym jsem se setkal. Aplikace Java + beany. Bean + Oracle .. funguje to funguje to najednou data v oracle DB narostou na urcitou mez ( nemluvim o skolnim prikladu s par set tisici recordy ) a sup cele to jde dolu ... analyzou se zjisti ze oracle/optimizer zacal ignorovat index ale Bean (tusim verze < 3) nema moznost vnutit hint kterej by problem resil. Takze se to resi v noci nekolikahodinovymi rebuildy indexu. To sou ty side efekty technologii .Net a Java. I zde plati zakon zachovani energie, to co je usetreno na vyvoji (RAD) je teze vykoupeno v provozu. Tot muj nazor.

Souhlasím  |  Nesouhlasím  |  Odpovědět
jura555  |  13. 08. 2009 08:10  |  Microsoft Windows Vista Firefox 3.0.13

No a ze Oracle zacal neco ignorovat je problem Javy nebo Oraclu?

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 08:20  |  Microsoft Windows XP Firefox 3.5.2

kazdej jen trochu slusnej programator kterje s oraclem nejakej patek zije o tomhle vi a vi ze existujou hinty a pouziva je. Nebo jinak myslite si ze sefa bude zajimat, sefe ono to sice nefunguje ale ja za no nemuzu muj kod je v poradku to jenom neco hapruje v oracle ? To je totiz mozna jadro pudla tech dnesnich rychlokvasek co se nazyvaj programatory ( vetsina z nich nevi kolik bitu ma bajt) a naklikaj si to v tom ci onom. A pak cumej jak tele na novy vrata ze to nefunguje.

Souhlasím  |  Nesouhlasím  |  Odpovědět
13. 08. 2009 08:35 | Microsoft Windows XP Maxthon 7.0

... ale vždyť píše, že hint nejde použít...?!

Souhlasím  |  Nesouhlasím  |  Odpovědět
jura555  |  13. 08. 2009 09:20  |  Microsoft Windows Vista Firefox 3.0.13

No ja nevim, ale to Vase vyjadreni nema hlavu ani patu. Chybu ma teda Oracle a muze za to java s .netem a programatorskyma rychlokvaskama? Zajimave....

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 09:32  |  Linux Mozilla 1.9.0.13

To byl jenom priklad. Urcite by se hodne podobnych zhovadilosti naslo v .Netu. Ona je uz zajimava geneze .Net (C#). M$ pri svem velikastvi zacal mit tendenci ohybat javu k obrazu svemu. To mu Sun zatrhnul tak si vytvoril na just C# ( klon javy ) s nekolika pridanyma vlastnostma.

Souhlasím  |  Nesouhlasím  |  Odpovědět
jura555  |  13. 08. 2009 10:57  |  Microsoft Windows Vista Firefox 3.0.13

No a co mel M$ jako delat. Chtel neco typu javy na windows. Napred chtel javu ohnout, no Sun byl proti. Tak si udelal .NET. Mel byste pro M$ lepsi napad?

Souhlasím  |  Nesouhlasím  |  Odpovědět
focal.blade  |  13. 08. 2009 12:41  |  Microsoft Windows 7 Opera 9.64

A teď se na to podívejme bez přidané nenávisti k Microsoftu a řekněme si, jak to skutečně bylo a je. MS se pokusil zajistit, aby Java ve Windows byla reálně použitelná, vývojáři se mohli spolehnout na to, jak funguje a rozšířit její možnosti. Uživatelé by nemuseli postupně na každý stroj instalovat další a další verze enginu, kde pak dochází k legračním situacím, kdy dvě konkrétní aplikace nemohou koexistovat. Sun viděl že to nemá v rukou a lidé to používají a udělal, co udělal. Díky bohu za to, protože dnes máme mnohem lépe navržený .Net a Javě se lze stále častěji obloukem vyhnout.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 12:49  |  Microsoft Windows XP IE 8.0

s timto jedine souhlasim
uz jen objektovy model .NETu je mnohonasobne propracovanejsi nez ten javovsky

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 13:03  |  Linux Mozilla 1.9.0.13

Zadnou nenavist k M$ nemam, pouzivam jeho OS jakozto herni platformu na seriozni praci pouzivame Unixy. Naopak si myslim ze bylo spravne ze se M$ vydal cestou .Netu a C#. Pouze podpotykam ze jak .Net tak Java jsou z meho subjektivniho nazoru zlo a cesta spatnym smerem.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 13:06  |  Linux Mozilla 1.9.0.13

Jeste bych dodal proc si to myslim. Vede me k tomu nekolik duvodu mezi ty nejdulezitejsi patri neco co bych nazval .JAR hell a narocnsot na resourcy + iluze RADu. Vite ono kdyz mate unixovou masinu ze nekolik desitek tisic dolaru, kde jenom dokoupeni pameti neni levna investice a najdenou vam zacnou dodavat "reseni" postavena na jave kde co "reseni" to jedna spustena instance JVM, tak vam to tu masinu krasne zhrobi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 09:41  |  Linux Mozilla 1.9.0.13

Zaprvy it's not bug it's feature. Kterou z javy neslo ovlivnit. A psal jsem to jenom jako priklad toho jak jsou vsechny tyhle "nastroje" nedotazeny.

Souhlasím  |  Nesouhlasím  |  Odpovědět
HerrDoktor  |  13. 08. 2009 15:19  |  Microsoft Windows Vista Firefox 3.5.2

neda mi na tie vami vyssie spomenute "rychlokvasky" nereagovat.
Zacal som sa venovat programovaniu vo velmi rannom veku, presiel som vsetkym "zlom". Niesom ani stary ani mlady, no neoznacnujem sa za nejakeho "old school" guru len preto, ze nemam rad RAD tooly.
Viete, jedna vec je sto percentna a velmi jednoducha: ja zarobim skor a viac, ako vy. Mali by ste predsa vediet, ze zakaznikov nezaujima v com, a ako je to naprogramovane, ale skor to, ako rychlo mu to viete dodat a ci to robi to co ma (dalsim artefaktom je to, ako to vyzera (vid trebars WPF)). To ze to bude casom pomale je zas vec druha. Ale tiez je zname, ze firmy v tejto sfere (aspon tie male) sa neudrzia dlho cize zakaznik ma smolu a nemoze chciet po niekom update. Alebo naopak narastu a budu si moct dovolit diktovat pravidla (napriklad: "je to pomale? kupte lepsi server", atd.)
no offense ofcourse

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:10  |  Microsoft Windows XP Firefox 3.5.2

Vite ja ani tak nemam problem s tim ze si nejaka mensi firma koupi od nejake One man show firmy nejakej softik zbastlenej na miru ( to je asi OK ) problem nastava v momente kdy reseni ala Java nasadite do prostredi velky firmy a kdy tech reseni ala Java nejsou 2kusy ale desitky. Tady vsichni programatori (a asi i opravnene ) koukaji jenom na to zadani/zbouchani kodu/vydodani (maximalizace zisku v co nejkratsim case) ... jenze tim to nekonci, pak tu mame provoz. A ja proste rikam ze funguje zakon zachovani energie .. to co je "usetreno" na vyvoji ( protoze to slo tak krasne a rychle nabouchat v nejakym RADu a je irelevantni jestli jsou to Java + NetBeans/Eclipse nebo MSVS .Net/C# ) se krute vrati v provozu, a z toho plyne ma averze vuci RAD. Nakonec podotknu ze nejsem provozak aby nedoslo k mylce ze kritizuju to co me trapi z me provozni pozice.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  14. 08. 2009 09:49  |  Microsoft Windows XP IE 8.0

Nevím, ale jsou projekty, které fungují docela dobře a lidi na nich pracují zadarmo nebo jen za velmi malý honorář Začíná to u utilitekytypu WinMerge nebo třeba Lame a konční někdy u operačních systémů.
Podle vašeho tvrzení o energii by musely být všechny aplikace z ČR na nic, protože čeští kolegové vydělávají dva až třikrát méně, než jejich kolegové v USA. Přitom si myslím, že v antivirech má ČR docela slušnou pozici a mohl bych jmenovat i pár her, které byly rozhodně AAA tituly.
Víte, neberte si to nějak osobně, ale z mojí zkušenosti jsou nejhorší právě experti typu - já to dělám nejlíp a ostatní jsou lepiči kódu. Minimálně ti lepiči mají potenciál se něco nového učit a rozhodně větší ochotu pracovat v týmu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 10:09  |  Microsoft Windows XP IE 8.0

Ano bigsame, ale tyhle problemy mas vzdycky pri pristupu generalizace-specializace. Nikdy nebude mit obecnejsi navrh uplne vsechny vyrazove prostredky specializovaneho pristupu. To neni jen u Javy komunikujici s Oraclem, ale u tisice jinych prikladu.
To ale neni duvod se generalizaci vyhybat. Nebyt ji, dodnes bys napriklad kompiloval programy konkretne pro kazdy procesor.
Je z tebe videt, ze jsi zaujaty specializovanym pristupem. Podle me ti chybi odstup a nadhled, coz byva pro vetsinu programatoru bohuzel typicke. V tom pripade si ale nemyslim, ze zrovna ty bys mel mit to pravo hodnotit druhe.
Z pohledu generalizace a specializace si myslim, ze dobre generalizovane prostredi by melo mit i moznost pouzit bud cele specializovane prostredi (napriklad napsat u c++ prostredi cast kodu v assembleru), nebo aspon rozumne rozsahle specializovane vyrazove prostredky (napr. ony hinty, jak zminujes; zde uz to bude vzdy kompromis).

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 10:14  |  Microsoft Windows XP IE 8.0

A hlavne, ty nejsi ze stare skoly, ty jsi z blbe skoly. Stara skola neznamena, ze odmitala zobecnovani, pouze tech obecnejsich reseni nebylo tolik, jako byva dnes. Bohuzel s tou starou skolou splyvali i ti, kteri zobecnovani odmitali - neslo je jaksi rozpoznat, kdyz se na uhelnem kamenu obecnejsich reseni (napr. onen .NET, ktery proste neexistoval) svymi postoji nedelili.
Spousta dobrych programatoru z drivejsi doby velmi vita zobecnena reseni pro vyvoj typickych situaci, s moznosti resit specializovane ty netypicke.

Souhlasím  |  Nesouhlasím  |  Odpovědět
pepavondepo  |  13. 08. 2009 14:24  |  Microsoft Windows XP Firefox 3.5.2

A stará škola C++ znamená co? Před STL nebo až po tom, co se STL stal součástí standardu? Nebo snad před Boost či až nové C++0x, které má půlku Boostu ve standardu?
To, co popisujete vůbec není problém programovacího jazyka, který se pochopitelně vyvíjí, ale "programátorů a jejich kvalit.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 09:30  |  Linux Mozilla 1.9.0.13

zacinam mit dojem ze autori jazyka maji pristup k lepsim drogam nez ja ... nebo mozna autor prispevku ...
x = nejakej result set
pro kazdej prvek v result setu neni nahodou velky pismeno ? je .. tak ho uloz do jinyho reusltsetu ..
pro kazdej prvek z druhyho result setu vypis pismeno ...
to je programatorska konstrukce jako noha.. let je range promena ktera se defakto chova jako local promena..

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 09:58  |  Microsoft Windows XP IE 8.0

No nevim, mne teda dost divny prijde tvuj komentar. Byt autorem, asi bych v tom odstavci pripsal, ze to odpovida selectu ze selectu a uvedl, jak by to jinak vypadalo jako SQL dotaz (protoze LINQ koneckoncu je volaci konstrukce nahrazujici SQL dotazy, proto bych vsude uvadel odpovidajici nativni SQL dotaz pro srovnani). Nicmene clanek mi prijde prehledny a srozumitelny, je mi lito.
Spis to tve - "chova se de facto jako lokalni promenna" je a neni pravda. Pokud se v programovani trochu orientujes, tak tomuto pristupu se rika closure. Je jim prostoupen treba cely Ruby, v C#u ho muzes videt v anonymnich metodach napriklad. Na lexikalni a gramatickou analyzu closure ti jako tvurci kompilatoru nestaci totez jako pro lokalni promennou, protoze closure prestupuje kontext jednoho scopu do jineho.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 09:47  |  Microsoft Windows XP IE 8.0

Ano, ten polymorfismus zdroju dat pro LINQ je sice uchvatny z hlediska objektoveho pristupu, ale z toho duvodu, ze nad rozumne velkymi daty je LINQ 3 i vickrat pomalejsi nez odpovidajici specializovanejsi .NETova rutina (rekneme datareader u SQL), jsem jeste LINQ nikde nepouzil.
To si myslim, ze by u vyuky programovani melo zaznit, v objektivnim clanku bych krome vyhod cekal take nevyhody.
Dalsi nevyhodou (a to uz spolecnou vubec pro C# 3.0 syntaxi) jsou anonymni typy. Chapu, ze aby sel LINQ vubec naimplementovat, byly potreba zavest, presto nejsem vubec jejich pritelem. Navic v CLR, ktere je nativne silne typove, takze preklad tech uzasnych var-u do typu se musi dit v compile timu - proste takovy silneslabetypovy gulasek, ktery je nachylny k vyse zminenym castovacim chybam.
A lambda vyrazy... kapitola trosku sama pro sebe. Je par specifickych situaci, pro ktere jsou lambda vyrazy uzasne a nahrazuji se jinak jen dost komplexnim kodem, ale v typickem pripade lambda vyrazy zbytecne zneprehlednuji kod a jejich konstrukty byvaji tezko uchopitelne.
Clanek je ale napsan hezky a srozumitelne pro cloveka, ktery s LINQem neprisel do styku, jedina vytka smeruje prave k onem nevyhodam.
Nevim, kdo temata clanku urcuje, ale podle me by vedle primo kodovacich technik stalo za to psat take clanky jednak architektonicke (napr. predstaveni trivrstevnych a n-vrstevnych reseni, distribuovanosti apod.) a designovaci (ruzne konstrukce trid a vzory jejich pouziti) a taky abych tak... napsal... clanky obecne o logice a mysleni pri programovani. To je totiz to, co dela programatora programatorem hlavne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
13. 08. 2009 19:04 | Microsoft Windows XP Opera 9.64

A tyhle ficurky jsou naopak neco, co dela programatora klikacem a lenivym n00bem co v C++ nepochopi pointer. Ja mam .NET pomerne rad, ale tohle - no, vyjadril jsi to moc dobre. Idealni byl .NET 2.0 pristup. Umel vsechno, co jsem dodnes potreboval a zatim nic me neprimelo ucit se tyhle (rozto)divnosti novejch verzi. A kdyz uz vyhledavat nad mnozinou, mame tu snad delegaty, predikaty ci co a podobne. Pak pribejva konkurence z rad noobu...

Souhlasím  |  Nesouhlasím  |  Odpovědět
piErcE  |  14. 07. 2011 23:01  |  Microsoft Windows 7 IE 9.0

Jen tak pro vaši informaci ...
1) LINQ není zavislý na anonymních typech - k činnosti ho vůbec nepoužívá. Anonymní typy přišly až v ogeneraci novějším .NETU, než ve kterém přišel LINQ
2) kvuli linqu prisly tzv. "var" - a to NEJSOU anonymní typy. Anonymní typy jsou až "dynamic" proměnéé v .NET 4. u proměnných typu VAR nedochází k žádným problémem v castování, protože jejich datový typ je jasně daný už v okamžiku překladu ze zdrojáku do IL a překlad zhučí v okamžiku překladu ve visual studiu (či nantu, msbuildu, apod)
VAR je jen "syntaktický cukr". Ale ano, anonymní typy (čili "dynamic"), je zvěrstvo.
Prosím, nepomlouvejte něco, o čem nic neznáte.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 10:54  |  Microsoft Windows XP IE 8.0

Nemůžu si pomoct, ale v případě SQL mi přijde, že ten LINQ přesouvá akorát práci ze serveru na klienta, což je naprosto opačný postup, než který byl v téhle oblasti vždycky brán jako hlavní směr - totiž data zpracovává našlapaný server a lehký klient čte jenom výsledek.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 11:36  |  Microsoft Windows 7 Opera 9.64

Ono se to ve skutecnosti tak chova. Z LINQu vznikne expression tree a z nej se pak sestavi SQL dotaz, takze where apod. provadi SQL server a klient uz dostane jenom vysledek.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 11:46  |  Microsoft Windows XP IE 8.0

Jenže SQL Serveru není jedno, jestli voláte předkompilovaný stored procedure
SELECT a FROM x WHERE b = @param
nebo pomocí LINQu natvrdo voláte (posílá se snad jako text?)
SELECT a FROM x WHERE b = 1
SELECT a FROM x WHERE b = 2 atd.
Tohle je právě ten rozdíl v architektuř server-tenký klient, takže u toho LINQu mi tak trochu uniká účel

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 12:47  |  Microsoft Windows XP IE 8.0

Ano, to je dalsi argument proti LINQu na databaze. Vedle te pomalosti. LINQ i krome toho, ze je pomaly, nema sanci drzet exekucni plany, statistiky a kdovijakou dalsi havet, kterou si SQL server pomaha.
Ja vyhody LINQu vidim v te obecnosti. Kdyz nepotrebuju specializovane reseni a muzu mu polymorfne podhodit XML, objekt nebo jednoduchy dataset, to je pro me jako programatora velky kus usetrene prace.
Ale jinak pokud se budeme bavit jako architekti, tak s Vami uplne nesouhlasim.
Zaprve trochu nevidim tu tendenci mit nabuseny SQL server, aby toho pocital co nejvic. Ciste teoreticky muze SQL server delat v ulozenych procedurach i vypocty business logiky. Ale mit jako zamestnance programatora, ktery napise byt jediny radek business logiky do ulozene procedury, na miste ho propustim. Oddeleni vrstev je zkratka dulezitejsi princip nez moznost, ze by pak business logiku pocital i slabsi stroj. SQL server muze vykonavat maximalne vypocty na datove vrstve.
Zadruhe, u reseni, ktere maji v ambici vubec SQL server vyuzivat, by mela byt business vrstva stale oddelena v nejake serverove komponente, ktera (jedina) pobezi nad SQL serverem (bud na stroji SQL serveru nebo na jinem silnem stroji). Pokud se bude business logika pocitat v takove komponente, nevidim v tom zadny problem a urcite neplati, ze se pak presouvaji vypocty na tenke klienty. Ale urcite neni dobre reseni, aby se klienti pripojovali primo na databazi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 13:40  |  Microsoft Windows XP IE 8.0

Co se té obecnosti týče, je to sice hezké, ale v praxi asi sotva použitelné. Už vidím, jak přecházéte z SQL databáze na XML, přičemž si nemůžete vynachválit, jak jednoduché to bylo.
Dejme tomu, že pro projekty malého rozsahu se ten LINQ může hodit, ale jakmile přeroste projekt určitou mez, asi to nebude úplně ono. Problém je, že tohle se dá u jednotlivých komponent a vlastně i u databází obecně dost těžko předvídat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:14  |  Microsoft Windows XP IE 8.0

Ne nemyslim SQL, jak jsem psal vyse, pro praci s DB jsem LINQ nikdy nepouzil a ani bych nepouzil.
Spis jsem mel na mysli ty dalsi zdroje - objekty (hardcodovane), XML a kdovico Microsoft vyhrne priste. Asi bych na nejake use casy prisel, ale proste pausalne LINQ nepouzivam.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:21  |  Microsoft Windows XP IE 8.0

Kazdopadne mohu jen souhlasit s tim, ze LINQ si nezaslouzi takovou publicitu, jaka je prezentovana. Ale tak je to se vsim novym, ze.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 14:27  |  Microsoft Windows XP IE 8.0

Víte, taky mi docela přijde jako reklamní marketingová masáž. Ty výhody mi prostě nejsou na první pohled zřejmé.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:29  |  Microsoft Windows XP IE 8.0

Mne ano. Mne pro zmenu nejsou uplne zrejme pripady uziti. Stejne jako u lambda funkci.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:42  |  Microsoft Windows 7 Opera 9.64

Jednoducha ukazka pro priklad - mate FileInfo[] a potrebujete z nej udelat list souboru s velikosti vetsi nez 1MB. Napiste si to po staru a pak pomoci LINQ extension metody s lambda vyrazem a uvidite ten rozdil v prehlednosti kodu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 15:45  |  Microsoft Windows XP IE 8.0

Ne v prehlednosti, ale v delce, prehlednost (aspon pro me a par mych znamych) naopak snizuje.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:17  |  Microsoft Windows XP Firefox 3.5.2

No s tim XML je to taky krasna ukazka toho co by nikdy poradnej programator neudelal. XML pokud se nepletu bylo navrzeno jako format pro vymenu dat a na to je skvely. Jenze pak prisli lameri napadem do "skveleho" xml ukladat nativne data, xml datbaze. Kazdej kdo ma jen trochu rozumu si rekne, proboha ten overhead pri ukladani dat a jeste vetsi pri zpracovani. Bohuzel zijeme v dobe v jaky zijeme. Takze ackoliv vyvijime cim dal tim rychlejsi CPU tak programy na nich bezi cim dal tim pomaleji.

Souhlasím  |  Nesouhlasím  |  Odpovědět
focal.blade  |  13. 08. 2009 12:53  |  Microsoft Windows 7 Opera 9.64

Ne, všechno skutečně nelze napsat jako sp, rozhodně ne tehdy, pokud nechceme strávit vývojem databázové vrstvy 20x více času. On totiž celý koncept práce se SQL nebyl kdysi vymýšlen pro taková nasazení, jako jej dnes užíváme.
Pokud mluvíme o MS SQL (a myslím že asi ano), pak mám za to, že už řada verzí umí optimalizovat a ukládat si execution plány i pro často vykonávané ad-hoc dotazy.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 13:07  |  Microsoft Windows XP IE 8.0

Ano, umi, coz je prave ta statistika. Blby je, ze se ji na druhou stranu nekdy sverepe drzi a nepusti se ji
Ale u sp k tomu navic vybuduje staly velmi komplexni exekucni plan, ktery se pak teprve chova jeste, jako by byl vstupem u onech ad hoc dotazu (tzn. buduje se statistika a exekucni plan se upravuje vlastne podle parametru tech dotazu). Jinymi slovy ulozena procedura jde jeste o uroven vys nez jednotlive dotazy. Pro vypocty na datove vrstve idealni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 13:35  |  Microsoft Windows XP IE 8.0

Tenhle příspěvek snad nemůžete ani myslet vážně? Pokud vývojem optimálního řešení strávíte 20x víc času, tak už se to asi vyplatí hodit na databázi, protože jinak bude 20x času trávit každý uživatel při provozování vaší aplikace.
O tom konceptu SQL to slyším poprvé v životě.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:19  |  Microsoft Windows XP IE 8.0

Prave, taky mi jeho prispevek prijde v techto ohledech divny. Zaprve prave SQL jazyk ma nejvyssi pomer prace na prikaz (uz jen proto, ze je deklarativni, tedy mimo scriptu potom, ale to uz vlastne neni query language , takze spis to byva prave opacne, ze to, co napisu rychle SQL skriptem, napisu rekneme v C#u daleko pomalej.
A o tom konceptu take slysim poprve. Cetl jsem onehda jednu krasnou knizku od Kena Hendersona, znameho vyvojare MS SQL serveru, v jakem stavu byl server v ranych dobach (pred 7.0), ale co vim, vzdy byl vyvijen s ohledem na uchovavani obrovskych mnozstvi dat, sam Microsoft se schopnosti vyhledat radek (bohuzel uz neuvadi, ze jen jeden v clusterovanem indexu chlubi, kde to jen jde.
Mam pocit, ze si tady nekdo vymysli. A ja to nebudu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:21  |  Microsoft Windows XP Firefox 3.5.2

Bez urazky, ackoliv se M$ hoodne snazi a M$ SQL server bezpochyby roste porad je to proti Oracle slabej odvar.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mi.Chal  |  13. 08. 2009 19:42  |  Microsoft Windows XP Firefox 3.5.2

Nevidim duvod, proc by LINQ to SQL nemel v tomhle pripade pouzivat parametrizovane dotazy zrovna tak

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  16. 08. 2009 14:07  |  Microsoft Windows Vista Firefox 3.5.2

U uložených procedur si ukládá exekuční plán pro danou proceduru. (nebo její verzi). Při dalším spuštění už používá kešovaný exekuční plán pro tuto proceduru. U ad hoc SQL dotazů server exekuční plán nenačítá.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mi.Chal  |  16. 08. 2009 14:31  |  Microsoft Windows XP Firefox 3.5.2

Jak to ma MSSQL teda nevim, ale u nekterych db se cachuje exekucni plan a pokud se posle vicekrat stejny sql dotaz, tak se pouzije. Takze pokud se lisi pouze hodnotou parametru, tak se nemusi delat znovu. Predpokladam, ze mssql to tak delat bude taky (ale nevim, kde najit nejaky spolehlivy zdroj, z ktereho by se to dalo zjistit )

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  16. 08. 2009 16:15  |  Microsoft Windows Vista Firefox 3.5.2

U MSSQL se doporučuje vynutit rekompilaci procedury a tím i změnu exekučního plánu v případě, že se zásadně mění parametry dotazu a tím pádem i dotaz uvnitř procedury. Exekuční plány u dotazů se neukládají - jediné co se ukládá do cache jsou data z tabulek; příp. pohledů, které jsou při spuštění dotazu použity.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  16. 08. 2009 16:24  |  Microsoft Windows Vista Firefox 3.5.2
Mi.Chal  |  17. 08. 2009 09:16  |  Microsoft Windows XP Firefox 3.0.13

Neplyne z toho nahodou to, co jsem psal? Jinak ten clanek se podle vseho tyka SQL2000, u 2005 nebo 2008 to muze byt i jinak
Druha vec je, ze ten test v clanku je udelany spatne. Zasadni problem je v tom, ze u SP pouziva dotazy s parametry, zatimco u normalnich dotazu dosazuje hodnotu parametru natvrdo, coz jednak neni dobre treba z hlediska sql injection a druhak pak nelze pouzit ten cachovany plan. Pokud by se pouzil dotaz s parametry, tak je porad stejny.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mi.Chal  |  17. 08. 2009 09:18  |  Microsoft Windows XP Firefox 3.0.13

Jinak koukam, ze to co si psal (exekucni plan se necachuje) odporuje tomu, co pisou v tom clanku...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  17. 08. 2009 10:18  |  Microsoft Windows 7 Firefox 3.5.2

Já jsem v článku našel jen to, že exekuční plán se neukládá na disk.
Ale cachuje se. Proto se často používané procedury vkládají do startup procedury, aby byl exekuční plán uložen do paměti.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mi.Chal  |  17. 08. 2009 10:32  |  Microsoft Windows XP Firefox 3.0.13

To jo. Me slo o to, jestli se bude cachovat exekucni plan u normalnich dotazu a ne jenom pri volani procedur, aby se pri dalsim spusteni stejneho dotazu (lisiciho se max. v hodnotach parametru) nedelal znova.
Jestli se to uklada na disk nebo zustane v pameti je z pohledu uzivatele asi jedno (pokud neberu v uvahu delsi cas pri prvnim provadeni dotazu).

Souhlasím  |  Nesouhlasím  |  Odpovědět
Mi.Chal  |  17. 08. 2009 09:20  |  Microsoft Windows XP Firefox 3.0.13

Jinak podle tohoto clanku http://msdn.microsoft.com/en-us/library/ms181055.aspx... to vypada, ze by se to melo cachovat pro kazdy dotaz. Nepisou tam, ze by se to tykalo jenom SP

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  17. 08. 2009 10:42  |  Microsoft Windows 7 Firefox 3.5.2

Omlouvám se, exekuční plány se cachují pro každý dotaz, jen u stored procedur je server snadněji nalezne. U SP je vliv na výkon vyšší, už jen qůli parsování dotazu.
Mimochodem jsem našel další článek, který tuto problematiku zmiňuje:
http://www.simple-talk.com/sql/t-sql-programming/to-... ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
piErcE  |  14. 07. 2011 23:02  |  Microsoft Windows 7 IE 9.0

LINQ samozrejme pouziva variantu parametrizovaných dotazů.
SELECT a FROM x WHERE b = @param

Souhlasím  |  Nesouhlasím  |  Odpovědět
Aleq  |  13. 08. 2009 15:57  |  Microsoft Windows Vista Chrome 2.0.172.39

Jak kdy, jak kde.
Jsou situace, kdy mas 1 vykonej DB server, nekolik aplikacnich serveru a obrovsky mnozstvi klientu. Skalovat DB server (mit vic instanci) je vzdy komplikovanejsi nez jen prikoupit dalsi aplikacni server. Takze treba v SAPim svete se toho na DB zase tolik nenechava a na aplikacnim serveru se toho dela vic.
Samozrejme to ale neznamena, ze xi fetchnu celou tabulku z DB a pak si ji celou "lokalne" na aplikacnim serveru zpracuju

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 16:28  |  Microsoft Windows XP IE 8.0

Nojo, jenomze kdyz perzistovat musis, tak proste musis.
Jsou data, ktera se daji dotahat pri nabehu systemu znovu, ale tezko ti bude uzivatel treba SAPu akceptovat, ze se mu po spadnuti serveru nenacetla faktura, kterou tam predtim zadal.
A pak uz nezbyva nez skalovat prave DB, coz je teda nekdy fakt humus nejvetsi fialovy.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:23  |  Microsoft Windows XP Firefox 3.5.2

SAP a ten jejich silenej jazyk jsem videl pouze z letadla ale to co stvorili chlapci od Sieblu beru jako hodne povedenej zert a kdo si to koupi za ty penize je u me hodne velkej sprymar.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Aleq  |  14. 08. 2009 10:53  |  Microsoft Windows Vista Firefox 3.5.2

Siebel jsem nevidel vubec, ale kdo hodnoti system podobneho typu na zaklade jeho programovaciho jazyku je taky slusnej sprymar

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:14  |  Microsoft Windows XP Firefox 3.5.2

To se asi E.F.Codd obraci v hrobe ..

Souhlasím  |  Nesouhlasím  |  Odpovědět
nazzo  |  13. 08. 2009 13:09  |  Microsoft Windows XP Chrome 2.0.172.39

Po dostatečných zkušenostech s LINQ to SQL musím konstatovat, že jediná funkčnost, která stojí z hlediska profesionála za pozornost, je to automatické design-timové načtení a zapouzdření uložených procedur a jejich výsledků do tříd.
Vše ostatní - a tím mysím opravdu VŠE - je odpověď na otázku, na kterou se nikdo neptal, vyření problému, který nikdy neexistoval, a splněný úkol, který nikdo nezadal.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Flasi  |  13. 08. 2009 13:41  |  Microsoft Windows XP Firefox 3.5.2

Úkol, který nikdo nezadal? Problém, který nikdy neexistoval? To, že v dobách, kdy vládnou čistě objetkové jazyky se silnou typovou kontorlou, musíte k datům k datům přistupovat jako v době kamenné vám nepřipadá jako problém, který si zasluhuje řešení?
Čímž neříkám, že řešení via LINQ nemá mnoho chyb.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 14:06  |  Microsoft Windows XP IE 8.0

Nemůžu si pomoct, ale tohle přeobjektovávání vede jenom k neskutečnému užírání výkonu a tím viditelnému zpomalování běhu aplikací. Bylo by to určitě ok, kdyby výkon počítačů rostl. Ale dnes jsme svědky spíše opačného trendu. Výkon neroste už nějakých pár let.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:23  |  Microsoft Windows 7 Opera 9.64

To je nesmysl, pokud se bavime o LINQ2SQL (a to ho taky nepouzivam), pak urcite jeho pouzitim k viditelnemu zpomalovani behu aplikaci nedochazi - mozna u jednoduchych dotazu s velkym resultsetem - ale ve vetsine pripadu, vsechno "zdrzuje" stejne ten DB stroj a vliv LINQ2SQL je zanedbatelny.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:28  |  Microsoft Windows XP IE 8.0

Vazne ? clanku jako http://weblogs.asp.net/ryansmith/archive/2008/04... ... najdete na googlu cele tuny
vyzkousejte

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:33  |  Microsoft Windows 7 Opera 9.64

Ale vzdyt to pisu, ze to je znat jen u velkych resultsetu. Porovnani s 50 000 zaznamy neni uplne fer - kdy naposled jste na klientu pracoval s tak velkym poctem zaznamu?

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:43  |  Microsoft Windows XP IE 8.0

50000 zaznamu je velky resultset ??
To bych Vam veril, kdybychom se potkali pred 10 lety.
Co je potom podle Vas resultset o milionech ci dokonce miliardach zaznamu ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:44  |  Microsoft Windows 7 Opera 9.64

Ja mluvim o resultsetu a ne o poctech zaznamu v tabulce.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 15:44  |  Microsoft Windows XP IE 8.0

Aha, clanek nicmene mluvi o poctu zaznamu v tabulce. I kdyz je pravda, ze selectuje celou tabulku.

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:25  |  Microsoft Windows XP Firefox 3.5.2

Pardon 50 000 zaznamu se vam zda hodne ? To zijeme opravdu kazdy v jinem svete ..

Souhlasím  |  Nesouhlasím  |  Odpovědět
bigsam72  |  13. 08. 2009 23:28  |  Microsoft Windows XP Firefox 3.5.2

I resultset o 50 000 a vice zaznamech neni problem ... Vemte si vetsi firmu napriklad CEZ/mobilni operatory a to staci ty cesky , co treba cinani, brazilie apod ... a vemte si ze kazdymu zakaznikovy vystavi fakturu ta ma nejake polozky a ted si to trochu proansobte a dojdete k tabulkam o 500 milionech zaznamech s kteryma musite umet efektivne pracovat. To vam potom pride LINQ jako hodne velka zhovadilost a to je taky duvod proc jsem v podstate zacal tuto debatu ..

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 14:32  |  Microsoft Windows XP IE 8.0

Už jsem to tady rozváděl - je rozdíl, pokud máte na serveru uložené předkompilované parametrizované dotazy, nebo pokud posíláte každý dotaz jako SQL text. Jinými slovy tvrdíte, že veškeré vyšší funkce SQL Serveru jsou k ničemu, protože pokud máte přístup pouze k tabulkám, tak výkonostně nepoznáte rozdíl. To je podle mě docela absurdní, nemyslíte?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:35  |  Microsoft Windows 7 Opera 9.64

Aha, takze on asi vubec nejde pouzit LINQ to SQL se storkou, ze?

Souhlasím  |  Nesouhlasím  |  Odpovědět
vransen  |  13. 08. 2009 14:42  |  Microsoft Windows XP IE 8.0

V principu jde, ale všechny příklady jenom ukazují, jak používat v LINQu klasický SELECT a jak je to skvělé. Podle mě je to dost zavádějící. Pokud ale máte všechno definované v DB, tak pak už se mi ten LINQ zas až tak výhodný nejeví, naopak můžete úplně v klidu používat stávající řešení přístupu k datům

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:25  |  Microsoft Windows XP IE 8.0

No moment, tohle ale LINQ prece neresi. Kvuli LINQu prave zavadel anonymni typy, coz je v primem protikladu ve silne typovou kontrolou.
On ji sice ma, protoze CLR je silnetypove, takze se ten problem pristupu k datum jako v dobe kamenne jen prevedl pripadne na vyhazovani vyjimek. To tedy zadne reseni neni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 14:30  |  Microsoft Windows 7 Opera 9.64

Proc porad resis ty anonymni typy? LINQ se da pouzivat i bez nich (i kdyz mas pravdu, ze kvuli nemu tam jsou). I tak ale nevidim v anonymnim typu protiklad silne typove kontrole - porad je to typ, i kdyz anonymni :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 14:52  |  Microsoft Windows XP IE 8.0

No resim je proto, ze reaguju na prispevek, ktery opevuje silnotypove jazyky a to, jak si udajne LINQ dokazal poradit s prevodem DB .NET typu automaticky. Resim to proto, protoze je to lez, nedokazal.
Zavedl pouze neco, co prevadi problem typovani na problem vyhazovani vyjimek - ale to si muzu napsat i sam.
Anonymni typ jako takovy samozrejme silne typove kontrole nepodleha, protoze to neni silny typ. Netvrdim, ze to neni typ, tvrdim, ze to neni silny typ. Nastesti anonymni typ v podani C#u je stejne silny typ (jinak to ani nejde), akorat skryty za syntaxi. Proto jeho podklad (silny typ) typove kontrole podleha.
Kdyby byl anonymni typ opravdu anonymni typ, tezko by mohl silne typove kontrole podlehat, ze; v tom pripade by to opravdu v protikladu bylo, nechapu, co ti na tom neni jasne. Jak by asi ta kontrola vedela, co je tim spravnym zamyslenym typem, kdyz to programator v deklaraci jaksi nevyjadri ? To se pak tezko kontroluje

Souhlasím  |  Nesouhlasím  |  Odpovědět
Atray  |  13. 08. 2009 15:08  |  Microsoft Windows 7 Opera 9.64

No jak pises, anonymni typ v C# neni v rozporu s typovou kontrolou - coz je co jsem predim psal :) Proto nechapu, proc jsi psal o tom protikladu ..... Jinak uvidime, jak s tim do budoucna zamicha typ dynamic. V tuhle chvili se mi na rychlou praci bez durazu na maximalni vykon jevi nejlip ADO.NET entity framework.

Souhlasím  |  Nesouhlasím  |  Odpovědět
ricmat  |  13. 08. 2009 15:38  |  Microsoft Windows XP IE 8.0

Ja to myslel jinak.
1) Skutecny anonymni typ s typovou kontrolou v rozporu je.
2) V C#u to nastesti neni skutecny anonymni typ, ale neni to ani plnohodnotny silny typ (tzn. anonymni typ se silnetypovym podkladem). Proto lze typovou kontrolu provest.
3) Dan i za tu nepravou anonymni slataninu jsou nekdy vyhazovane castovaci vyjimky v runtime - to byla ma pointa. Aneb LINQ neresi to, co autor psal, ze resi - tzn. prevadeni SQL typu na .NETove typy. Pouze se tak na prvni pohled tvari, a to za cenu vyjimek a radoby anonymnich typu. To pro me neni reseni.

Souhlasím  |  Nesouhlasím  |  Odpovědět
pepavondepo  |  13. 08. 2009 14:19  |  Microsoft Windows XP Firefox 3.5.2

Doporučuji se vykašlat na LINQ2SQL a nasutdovat a používat LINQ to Objects. Zejména lambda výrazy!
Je neuvěřitelné, jak se zčitelní kód, který byl dříve přeplněn různými vnořenými for a foreach včetně if... else.
Tohle se MS doopravdy povedlo!
Mimochodem - víte, že C++ knihovna pro lambda výrazy je součástí Boostu od ~2001? Používá ji někdo z vás?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Davidoff77  |  14. 08. 2009 08:14  |  Microsoft Windows XP Firefox 3.5.2

Jak se tak divam na diskuzi, tak tady vidim nekolik zakladnich rysu diskuteru.
1) Programatori, kteri programuji a vedi kde co pouzit a jsou schopni najit kompromis mezi vykonem a prehlednosti kodu. Zaroven se nebrani novym vymozenostem, ktere jazyk poskytuje.
2) Lide, kteri jsou radi, ze se naucili implementaci C#.NET 2.0 a aby se nemuseli ucit dalsi rysy, tak jej radsi oznaci za necitelne, zbytecne, nevykonne a proste verzi od verzi horsi a horsi.
3) Lide, kteri radsi reknou, ze vse od M$ je k nicemu a radsi se ucit neco jineho. Ikdyz jeste jsem nezahlednul nikoho kdo rekl, ze c# je k nicemu a jedine objective C :)
Ale podivejme se, proc M$ dela co dela. Tak za prve, rozhodne nejsou nove rysy ukoly ktere nikdo nezadal. Mnoho rysu je navrzeno na zaklade pozadavku vyvojaru a rozhodne kazdy s dalsich rysu ktere M$ implementuje ma sve velke vyhody a opodstatneni. Stejne jako LINQ, ktery dokaze pro vyvojare vyborne zprehlednit kod, vyhnout se nekterym chybam apod. Na prvni pohled je to mozna tezko citelne pro nekoho, kdo nema technologii vzitou. A ten kdo tvrdi, ze RAD je slepa ulicka, tak asi malo dela v komercni sfere. Neni cas vyvijet aplikaci nekolikanasobne delsi dobu, je prilis velka konkurence, tlak zakazniku apod. A pokud mi nekdo nabidne nastroj, kterym vyvoj zkratim na zlomek casu u jineho nastroje, tak ho proste vezmu. Navic pokud se jedna o tak vyzkouseny framework jako .NET. A co se tyce optimalizace, vykonu apod.? Priznejme si, ze na hromade mist je vykon aplikace dostatecny a na mistech kde ne se porad da najit jine reseni. A mimochodem platforma .NET je podle mych zkusenosti vykonna dostatecne a pokud ne, tak je to vetsinou chyba navrhu nebo moje chyba jakozto programatora.
A mimochodem, co se tyce neprehlednosti. Kazdy kod bez komentaru muze byt hodne necitelny a muze byt napsan treba v QBasicu :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
14. 08. 2009 09:30 | Microsoft Windows Vista Firefox 3.5.2

Pěkně jsi to vystihl. Je to o kompromisu.
Ještě bych dodal- mnohdy kdy naše slavné zákonodárstvo schválí nějaký zákon na poslední chvíli a je potřeba během krátké chvíle tyto často velké změny zavést do programu, člověk u toho sedí 13-14 hodin denně aby se to stihlo, nevidí na oči, bolí záda i zadek tak potom vezme za vděk jakémukoliv ulehčení práce a jakékoliv technologii která minimalizuje možnost vytvoření chyby (silné datové typy, garbage collection ap.). Prostě praxe je dost odlišná od programování pro zábavu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor

Aktuální číslo časopisu Computer

Megatest 20 procesorů

Srovnání 15 True Wireless sluchátek

Vyplatí se tisknout fotografie doma?

Vybíráme nejlepší základní desky