Question

I have the following query:

;WITH valRules AS   
(   SELECT vr.valRuleID, Count(*) AS totalRows, Sum(vt.test) AS validRows  
    FROM (SELECT NULL AS x)    AS x  
    JOIN #itemMap              AS IM  
      ON IM.lngitemID       = 1  
    JOIN tblValidationRule     AS vr  
      ON IM.RuleID          = vr.valRuleID  
    JOIN tblValidationRuleDetl AS vrd  
      ON vr.valRuleID       = vrd.valRuleID
    LEFT JOIN #ValTest         AS vt  
      ON vrd.type           = vt.type     
     AND vrd.typeSequence   = vt.typeSequence  
     AND vrd.valRule        & vt.Response > 0   
     OR (vrd.valrule = 0 AND vt.response = 0 )  
     GROUP BY vr.valRuleID  
)  
SELECT Count(*)   
    FROM valrules  
    WHERE totalrows = validRows

Note the CTE, and the Bitwise Operator in the Left Join Condition. How this is currently used is in a stored procedure that takes values from a C# application in the form of an XML variable. The XML Variable is placed into table #valTest. All columns are of datatype INT. If vt.Response is valid for vaRule, the result of & will be greater than zero. (i.e. 31 & 8 = 8 but 12 & 2 = 0). vt.Test column contains the number 1 for each row, so that it may be summed up (nulls are automatically excluded) to get a count of the validations that pass by rule. Each rule has a number of attributes that must pass validation for success. If the number of attributes is equal to those that passed, we have success.

In an effort to reduce calls to the database, the goal is to cache ALL the rules in the ASP.NET cache and handle validation localy. The developers are asking for a de-normalized version of the validation data with the claim that the SQL Set based operation is not a simple task in C# with Linq. From what I have looked into, I would agree. At this point my investigation shows the bitwise comparison in the join condition is particularly problematic.

The main question is how is can this be converted to something that uses Linq on the C# side? Or, are there more efficient ways to deal with this on the client side and Linq is not one of them (i.e. just give them flat data)?

thanks

Answer 1

LINQ-to-SQL isn’t going to do anything quite as bespoke as that query. Which isn’t a criticism of either LINQ-to-SQL or the query: simply, there are limits.

There are two ways I would approach that:

1: as a parameterized TSQL query via ExecuteQuery<T> – i.e.

var result = db.ExecuteQuery<YourType>(@"your query here with {0}, {1} etc",
                 arg0, arg1, ...);

2: write that TSQL a udf mapped into the data-context:

var result = db.YourUdf(arg0, ...);

Both are valid and will work with LINQ-to-SQL; personally I prefer the first approach, but the UDF approach allows greater re-use within the DB layer, at the expense of having more complex deployment (i.e. app tier and db tier all at the same time).