Soci blog

A feladvány, hogy van sok szűrési feltétel, ezekre szűrni kell, ha van érvényes értékük, vagy kihagyni a szűrésből, ha nincs.
A feladatra SQL Server esetén bool algebrás megoldást írnék:

select * from tabla
where
(@p1 is null) or (@p1 = col1)
and
(@p2 is null) or (@p2 = col2)
...
option(recompile)

Az option hint azért kell, mert így a nullos paraméterek teljesen kiesnek a tervből, csak a valódi szűrésekre készül terv. Ez szerintem óriási dolog, érdemes észben tartani.

Ugyanezt a logikát linqval is el lehet játszani, ref típusokkal kb. így:

var x = from z in Valami
where (p1 == null) || (p1 = z.col1)
&&
(p2 == null) || (p2 = z.col2)

Egy másik megoldásban azt használjuk ki, hogy késleltetett módon értékelődnek ki a kifejezések, így lehet őket láncolni. Itt látható ez a megoldás, és még más megközelítések is.

A harmadik megoldásban írhatunk egy saját szűrő operátort is erre a célra. Az előbbi címről:

public static IQueryable<TSource> WhereIf<TSource>(
    this IQueryable<TSource> source, bool condition,
    Expression<Func<TSource, bool>> predicate)
{
    if (condition)
        return source.Where(predicate);
    else
        return source;
}

Nehéz megindokolni, melyik megoldás a jobb.

Az utóbbi hetekben 3 beta vizsgán voltam, csak most valahogy elkapott az őszi terméketlenség, és nincs kedvem írni.

Na, de azért próbálom bepótolni.
A vizsga igen jelentős részben az ún. occasionally connected rendszerekről szól. Ezek olyan appok, amelyek tudnak online és offline is működni, amikor offline-ok, akkor valamiféle lokális cache-ben tárolják az korábban letöltött adatokat, majd ha újra online lesz a gép, akkor visszaszinkronizálnak.
Nyilván erre ezerféle megoldás adható, a dataset, dataadapter, xml hármastól a lokális sql server compact vagy expressig. A vizsga elég rendesen körbejárja a kérdést, milyen helyzetben melyiket érdemes használni. Azaz aki nem tette meg, nézzen után a compactnak.
Jó tudni a synchronization frameworkről, illik valamennyire ismerni az Entity Frameworköt, de nem mélyen, az vizsga nem arról szól.
Jó tudni róla, hogy lehet hangolni a GC-t, hogy ne aggresszívkodjen annyira, erre is rákérdeznek, hogyan?
És még:
Milyen módszerekkel lehet logolni az appból?
XCOPY vs. ClickOnce vs. MSI
GAC kezelés
Hiba riportolási módok
WPF vs. WinForm és integráció
Role based secu
Régi kód migrálása
Némi testing
Némi winforms (nem sok)
Riportok
Saját komponens VS integráció
Kicsi Linq
Kicsi WCF
Caching módszerek
Threadpool kimerülés
Vakok támogatása

Kb. ennyi ugrik be. Eléggé maszatolós, pics-pöcs vizsga, nem szeretem az ilyeneket, elég általánosak a kérdések ahhoz, hogy ne lehessen cache-ből megválaszolni őket, hanem még gondolkodni is kelljen rajtuk. Az ilyen vizsgák fárasztóak. :)

Másik kolléga véleménye a vizsgáról.

Az olyanoknak, mint én, akik csak ugatják a témát hasznos ez.

Az előző cikkemmel csak az volt a célom, hogy megmutassam, hogyan lehet megírni ugyanazt a lekérdezést kétféle módon, a teljesítményüket nem is vizsgátam, mivel érzésre egyik se volt túl lassú.

Laci kommentjében a teljesítmény kérdésre hívta fel a figyelmem, hát megnéztem, mi itt a helyzet. Nos, megúszta a LINQ, pedig nem akartam neki reklámot csinálni. Pontosan ugyanolyan teljesítményű lett a két megoldás, ami nem csoda, hisz pontosan ugyanaz az SQL végrehajtási tervet eredményezik! Egyetlen különbség, hogy a sorszámozást LINQ esetén csak procedurálisan tudtam megcsinálni, így a LINQ sql-es kódjában az nem szerepel, de ennek költsége nem is jelent meg a tiszta SQL megoldás végrehajtási tervében, annyira kicsi.

A lényeg tehát, hogy a LINQ nem feltétlenül lassú, sőt, teljesen egyenértékű lehet a hagyományos SQL-es megoldással. De miért is lenne más? Hisz egyszerűen arról van szó, hogy másképp írom le ugyanazt a specifikációt, az egész hatékonysága azon múlik, mennyire okos a LINQ to SQL sqlgenerátora. A jelek szerint egyszerűbb lekérdezésekre tökéletes.

Aki nem hiszi amit írok, nézze meg az alábbi képet (rákattintva nagyban).

Melyik a szimpatikusabb?

select bucid, score, countMatchedEcid, ROW_NUMBER()
OVER(ORDER BY score DESC) AS 'rank'
from (
select
b.ucid as bucid,
a.ucid as aucid,
sum(w.weight) as score,
count(*) as countMatchedEcid
from EcidNameValueSummary a,
genecidparts b,
weights w
where a.id=b.id
and a.value=b.value
and a.ucid!=b.ucid
and w.id=a.id
and w.allowed=1
and w.limit>=a.countEcids
and a.ucid=@ucid
group by b.ucid, a.ucid
) as hits

var matchQuery = from t in
    (from a in c.EcidNameValueSummaries
    join b in c.genecidparts
    on a.id equals b.id
    join w in c.Weights
    on a.id equals w.id
    where w.allowed == 1
    && w.limit >= a.countEcids
    && a.value == b.value
    && a.ucid != b.ucid
    && a.ucid == ucid
    select new
    {
        bucid = b.ucid,
        aucid = a.ucid,
        score = w.weight1
    })
group t by t.bucid into g
orderby g.Sum(e => e.score) descending
select new RankEntity
{
    Ucid = g.Key,
    Score = g.Sum(e => e.score) ?? 0,
    CountMatched = g.Count(),
    Rank = 0
};

BindingListCollection<RankEntity> ranks =
new BindingListCollection<RankEntity>();
int i = 1;
//It would be cool to do this with linq, but...
foreach (RankEntity e in matchQuery)
{
    e.Rank = i++;
    ranks.Add(e);
}
return ranks;

És emellett, a ROW_NUMBER-t át tudná nekem valaki fordítani LINQ-ra?

Mi van, ha egy LINQ kifejezésben olyan szűrést szeretnénk végrehajtani, amit a LINQ2SQL réteg nem tud okosan végrehajtani, mert pl. TSQL függvényt kellene használnunk a where feltételben?
Ha nem ügyeskedünk, átjön a 100 millió sor az adatelérő rétegbe, aztán szűr a LINQ maga. Szép is lenne.

No, az okosság az ilyen esetekre az, hogy lehet használni TSQL függvényeket a LINQ where feltételben. Ettől még nem lesz index seek, de legalább a szerver szűr.

A linkelt példát kipróbáltam, tényleg a szerver szűr.

AdwentureWorks-szel:

AWDataContext dc = new AWDataContext();
dc.Log = Console.Out;

var q = from o in dc.PurchaseOrderHeaders
        where dc.WeekOfYear(o.OrderDate) == 23
        select o;

foreach (var item in q)
{
    Console.WriteLine(item.OrderDate);
}

ALTER FUNCTION WeekOfYear(@Date DateTime)
RETURNS Int
AS
BEGIN
RETURN (CAST(DATEPART(ww, @Date) AS INT))
END

Az SQL, ami bemegy a szerverhez:

SELECT [t0].[PurchaseOrderID], [t0].[RevisionNumber], [t0].[Status],
[t0].[EmployeeID], [t0].[VendorID], [t0].[ShipMethodID], [t0].[OrderDate],
[t0].[ShipDate],
 [t0].[SubTotal], [t0].[TaxAmt], [t0].[Freight], [t0].[TotalDue],
[t0].[ModifiedDate]
FROM [Purchasing].[PurchaseOrderHeader] AS [t0]
WHERE [dbo].[WeekOfYear]([t0].[OrderDate]) = @p0
-- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [23]
-- Context: SqlProvider(Sql2005) Model: AttributedMetaModel Build: 3.5.21022.8

Nézegettem az SQL 2008 könyvet, és az ottani példa alapján kedvem támadt kipróbálni a LINQ-t. Tetszik, nem tudom valódi appokban tényleg jó-e, de babrálni vele érdekes.

using System;
using System.Linq;
using Microsoft.SqlServer.Management.Dmf;

class Program
{
    static void Main(string[] args)
    {
        ConsoleColor origColor = Console.ForegroundColor;

        var fc = from f in PolicyStore.Facets
                 orderby f.DisplayName
                 select f;
        foreach (var fi in fc)
        {
            Console.ForegroundColor = ConsoleColor.Yellow;
            Console.WriteLine("Facet {0}:", fi.DisplayName);
            Console.ForegroundColor = origColor;

            var props = from f in fi.FacetProperties
                        orderby f.Name
                        select f;
            int i = 0;
            foreach (var pi in props)
            {
                Console.Write(pi.Name);
                if (i++ > 0)
                    Console.Write(", ");
            }
            Console.WriteLine();
            Console.WriteLine("-----------------------------------");
        }
    }
}

Állítólag ez a DMF nagy durranás az adminoknak, tessék örülni neki és olvasni az ingyenes fejezetet.

Aki ezek után azt mondja, hogy nem volt honnan tanulnia, nem hiszek neki. :)

Van itt még Ajax meg SilverLight könyv is.

Nem új a dolog, de a LINQ kapcsán láttam meg a reflectorban ezt a jószágot: HashSet.

Nagyon örülünk, ez hiányzott a fwből. A fákra viszont kicsit még rámászhatnának, mert azok továbbra is hiányoznak…

Tanulgatom a bestiát, találtam hozzá egy jó leírást.

Rico Mariani neve szerintem ismerős a .NET programozók körében, ő az MS egyik performace-hangoló embere.
Mivel kedvencem az optimalizálás, a blogjára mindig odafigyelek. Most a DLinket vette górcső alá, eddig 4 cikket írt róla (1 2 3 4).
A 4.-ben már a még ki nem adott Beta2-vel foglalkozik, amiben már majdnem olyan gyors a Linq mint a sima kézi sql, sőt, módosításoknál 4x gyorsabb. Miért? Olvassátok el a cikkeket. :)