LINQ Странный вывод SQL

1

Поэтому я с этим запросом LINQ получаю что-то довольно странное для вывода SQL.

public string GetHeaders(string header,string lec, string state)
{
    string[] states = { "FL", "CA", "IN", "AL", "MI" };
    string[] updatedstateslist = states.Where(x => x != state).ToArray();
    var headers = (from h in db.Headers
                   where h.Description.Contains(header) & h.LEC == lec & !updatedstateslist.Contains(h.State)
                   select new
                   {
                       description = h.Description,
                       sic = h.SIC,
                       yphv = h.YPHV,
                       state = h.State
                   });

SQL OutPut выходит с

SELECT 
    1 AS [C1], 
    [Extent1].[Description] AS [Description], 
    [Extent1].[SIC] AS [SIC], 
    [Extent1].[YPHV] AS [YPHV], 
    [Extent1].[State] AS [State]
FROM [dbo].[Headers] AS [Extent1]
WHERE ([Extent1].[Description] LIKE @p__linq__0 ESCAPE N'~') 
  AND (([Extent1].[LEC] = @p__linq__1) OR (([Extent1].[LEC] IS NULL) AND (@p__linq__1 IS NULL))) 
  AND ( NOT (([Extent1].[State] IN (N'FL', N'CA', N'AL', N'MI')) AND ([Extent1].[State] IS NOT NULL)))

конкретный раздел, который является странным, (@p__linq__1 IS NULL)

Я не могу понять, какая часть LINQ вызывает появление одной маленькой секции. Если бы я знал, что могу переписать Linq, чтобы этого не случилось.

Теги:
linq

1 ответ

3
Лучший ответ

Здесь нет проблем, структура правильная.

Он должен преобразовать предикат С#

h.LEC == lec

в эквивалент SQL.

Одна интересная особенность SQL заключается в том, что предикат NULL = NULL вычисляет NULL, которое при приведении в логическое значение становится false. (см. этот вопрос)

Таким образом, структура должна преобразовать это в предикат sql, который определяет, имеют ли они оба значения, равные или оба являются нулевыми. Если вам нужно было написать это вручную, вы в конечном итоге пишете то же самое:

([Extent1].[LEC] = @p__linq__1) 
             OR 
(([Extent1].[LEC] IS NULL) AND (@p__linq__1 IS NULL)))
  • 0
    Добавление примечания: переменные связывания хороши для производительности БД. Они позволяют модулю выполнять уже скомпилированный запрос, потому что механизм уже знает план выполнения; меняются только эти переменные одного типа. Если вы избегаете связывать переменные, вы стреляете себе прямо в ногу, насколько производительность идет.
  • 0
    Если я выполню этот запрос к базе данных и удалю этот раздел ИЛИ (([Extent1]. [LEC] НЕДЕЙСТВИТЕЛЕН) и (@ p__linq__1 НЕДЕЙСТВИТЕЛЕН)) я получу ожидаемые результаты. Поэтому я очень смущен тем, что вы говорите, что все работает правильно, когда результаты не совпадают. Я работаю с SQL довольно давно, но по общему признанию я не эксперт ни в коем случае. Это сказанное, Вы могли бы объяснить свой ответ немного больше
Показать ещё 5 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню