Vývojářský blog Tomáše Hercega

RSS Feed

.NET Tips   2D   3D   Aplikace   ASP.NET   C#   C++   HTML+CSS   Internet   Javascript   Office   Silverlight   SQL   VB.NET   VB6   VbNet.cz   Vista   VS   Život, vesmír a vůbec   Všechny články

Vyhodnocení: Programátorská hádanka aneb znáte LINQ to SQL a Entity Framework?

Před týdnem jsem na blogu zadal programátorskou hádanku, která se skládala z několika otázek. Na mail mi přišlo pár řešení (ano, správně jste poznali, že e-mail byl zakódován v PowerShellu), většina z nich byla správně.

 

1. Co je špatně na následujícím LINQ dotazu? Jak by se to dalo opravit?

 var categoryName = dc.Products.Single(p => p.ProductID == 1).Category.CategoryName;
 Console.WriteLine(categoryName);

Tato první otázka byla jednodušší. V zásadě ten dotaz fungoval a vracel to, co se od něj čekalo. Jest zvláštností světa programátorského, že i věc, která funguje, může být úplně blbě. Co je zde za problém?

[Pokračování článku]

Kategorie: SQL, C#, Život, vesmír a vůbec        

Programátorská hádanka aneb znáte LINQ to SQL a Entity Framework?

Používat LINQ to SQL či Entity Framework jsou zde již poměrně dlouho a mnozí z nás je používají. Známe je ale dobře a víme, co nás kdy může potrefit?

Mám zde dvě hádanky, které čekají na řešitele. Autor nejlepší odpovědi (stručné, ale kompletně pokrývající a vysvětlující daný problém) dostane velmi pěknou a užitečnou cenu. Není nutné spěchat, pořádně si odpovědi rozmyslete.

Bacha! Může to taky být chyták – ptám se, jaká je tam chyba, ale přitom je ten kód naprosto v pořádku a funguje.

1. Co je špatně na následujícím LINQ dotazu? Jak by se to dalo opravit?

 var categoryName = dc.Products.Single(p => p.ProductID == 1).Category.CategoryName;
 Console.WriteLine(categoryName);

[Pokračování článku]

Kategorie: SQL, Život, vesmír a vůbec        

Schizofrenní ORM v podání Microsoftu

Dnes již si těžko dovedu představit psát aplikaci pracující s databází bez Linq To SQL či bez Entity Frameworku. Přes všechny nevýhody, které mají (moc jich naštěstí není), se s nimi pracuje velmi pohodlně a zvyšují nám produktivitu.

Pokud bychom srovnali jejich funkce, z 90% umí to samé. Jak Linq To SQL, tak i EF mají každý pár funkcí, které ten druhý nemá.

Linq To SQL je mnohými považován za takovou technologii pro začátečníky, hračku, “parodii na ORM” a já nevím, co ještě. To, že podporuje pouze jeden model dědičnosti, a to zrovna ten, který se mi moc nelíbí (Table Per Hierarchy - celá hierarchie tříd je v jedné tabulce a používají se z ní jen některé sloupce). Entity Framework je ve své druhé verzi (označené fikaně jako verze 4, aby to bylo kompatibilní s verzí .NETu) je naproti tomu téměř všemi uznávaný nástroj, který má sice širší možnosti modelování (struktura entit v EF se nemusí krýt přesně se strukturou tabulek v databázi), ale pár věcí, které jsou v Linq To SQL samozřejmostí zase neumí a člověk se jenom ptá “proč sakra”.

Poslední měsíc a půl trávím veškerý svůj volný čas psaním CMS s názvem Uraeus. V databázi se všechno motá kolem tabulky Items, která má jeden sloupeček typu HierarchyID. Každá položka může mít různé atributy, oprávnění (která se dědí) atd., jsou tam různé content-types, každý typ má svou vlastní tabulku, např. Articles, Categories atd., přičemž jsou s položkou provázány vazbou 1:1 přes sloupec ItemId.

Celý obsah CMSka je jeden velký strom a většina dotazů na data je typu “vytáhni mi potomky této položky, vyfiltruj je a nastránkuj je”. Inu napsal jsem si funkci vracející tabulku (fuj to je hrozný překlad “table-valued function”), které předám ID kořenové položky a ona mi vrátí všechny její potomky. Funkce se v SQL totiž používají jako tabulky, dají se filtrovat, řadit, stránkovat atd. Vybrat z funkce můžete třeba SELECT * FROM [dbo].[MojeFunkceVracejiciTabulku](parametr, parametr) atd.

[Pokračování článku]

Kategorie: SQL, C#, Život, vesmír a vůbec        

Pozor na SP_EXECUTESQL

Posledních pár měsíců bylo načítání titulní stránky VbNetu relativně pomalé. Před pár týdny mě to konečně naštvalo tak, že jsem zjistil, co to dělá (seznam Moje témata), ale protože jsem neměl čas, jen jsem ho schoval.

Dnes jsem konečně začal zjišťovat, čím to bylo, a proč sice složitý, ale nikterak zapeklitý dotaz trval na lokálu kolem 15 sekund (na ostrém serveru to bylo o trochu rychlejší).

Ten dotaz se díval do tabulky s tématy ve fóru, pro každé téma si joinem vytáhl první příspěvek a v něm hledal shodu na autora nebo IP adresu (aby to nějak fungovalo i nepřihlášeným uživatelům). Bylo mi jasné, že při několika tisících témat ve fóru nebude hledání podle IP, což je pole typu string, nikterak rychlé, proto jsem samozřejmě na sloupci udělal index. Nepomohlo to ovšem vůbec.

Zkopíroval jsem tedy SELECT z aplikace do SQL Server Management Studia, před něj nadeklaroval a zinicializoval ty dva parametry, které uvnitř měl. Když to celé spustím, je to hotové hned, žádných 15 sekund. Nechápavě na to koukám a po chvíli spouštím profiler.

Dotaz stejný, akorát aplikace ho spouští přes SP_EXECUTESQL, hodnoty parametrů stejné, ale z management studia je to hned a z aplikace za 15 sekund. Nechápu.

[Pokračování článku]

Kategorie: SQL        

Řešení jednoduché SQL hádanky

Před dvěma týdny jsem na svém blogu uveřejnil SQL hádanku. Jednalo se o to, jak v SQL vybrat z určité tabulky se sloupci Datum a Skupina pět nejnižších dat z každé skupiny, přičemž skupinou se myslí záznamy, kterémají stejnou hodnotu ve sloupci Skupina.

Během pěti minut po zprávičce na mém Twitteru mi přistály v e-mailové schránce 3 správná řešení. Bylo to samozřejmě od lidí, které znám a od kterých jsem to čekal. Evidentně už podobný dotaz někdy museli psát také (anebo četli Altairův článek), proto věděli, jak se to dělá.

Během následujících hodin a dní mi už začaly chodit spíše řešení, kde čtenáři ranking functions v MS SQL Serveru neznali, anebo je nenapadlo, že by se daly použít. Já sám jsem na blog tuto hádanku napsal a až po příchodu prvního řešení jsem si vzpomněl na to, že znám klíčové slovo PARTITION BY, akorát mě nenapadlo ho použít. Ono se to dá i bez něj (že by další hádanka?), ale ideální řešení to není, i když bude pravděpodobně skoro stejně rychlé.

Rozhodně není správné řešení toto, protože tady pro každý řádek pouštíte jeden SELECT dotaz. Pokud řádků bude sto tisíc, děláte sto tisíc a jeden SELECT. Časová náročnost dotazů se sice nedá počítat jen podle počtu prováděných selectů, ale jako takový základní odhad to většinou stačí. Ona si konec konců databáze ty dotazy dost optimalizuje, na druhou stranu na to není dobré vždy spoléhat. Takhle tedy rozhodně ne.

SELECT * 
  FROM @t [t] 
  WHERE 
    [t].[Number] IN (SELECT TOP 4 [Number] FROM @t WHERE [CategoryId] = [t].[CategoryId] ORDER BY [Number]) 
  ORDER BY [t].[CategoryId], [t].[Number]

[Pokračování článku]

Kategorie: SQL