Как определить, следует ли использовать join в linq to sql?

#c# #asp.net #sql-server #linq-to-sql #join

#c# #asp.net #sql-сервер #linq-to-sql #Присоединиться

Вопрос:

Мне просто интересно, как мы можем определить, использовать join или нет linq to sql .

Например. допустим, у нас есть две такие таблицы

 Table 1   Customer
          id
          name

Table 2   addresstype
          id
          address1
          customerid
 

и

 var address = from cu in Customer
              from ad in addresstype
              where cu.id == ad.customerid
              select ad;
 

или

 var address = from cu in Customer
              join ad in addresstype on cu.id equals ad.customerid
              select de;
 

Оба способа одинаковы. Есть ли какая-либо разница в производительности?

Также второй метод, выдаст ли он ошибку, если совпадений нет?

Комментарии:

1. Второй метод не выдаст ошибку, если совпадений нет… Это не даст никаких результатов, как это сделал бы эквивалентный SQL-запрос

Ответ №1:

Вы используете linq для сущностей или linq для SQL? Если это первое, то вы можете избежать обоих из них, определив свои отношения в модели и используя свойства навигации. Это был бы самый простой способ сделать что-то

Комментарии:

1. Ну, вы не можете использовать мое предложение 🙂 возможно, в следующий раз рассмотрите linq to entities!

2. LINQ to SQL поддерживает ассоциации, которые совпадают со свойствами навигации EF.

Ответ №2:

По сути, эти два запроса LINQ эквивалентны следующим запросам SQL:

  select ad.*
 from Customer cu, AddressType ad
 where cu.ID == ad.CustomerID -- I assume this was meant by the OP
 

и

 select ad.*
from Customer cu
  inner join AddressType ad on cu.id = ad.CustomerID;
 

Разница между этими двумя запросами в основном семантическая, поскольку база данных будет выполнять одно и то же в обоих случаях и возвращать один и тот же набор результатов для обоих запросов.

Я бы предпочел join синтаксис как в SQL, так и в LINQ, поскольку он определяет явную связь между двумя таблицами / сущностями, которая подразумевается только в версии без объединения.

Ответ №3:

Это, кажется, один и тот же запрос, они возвращают тот же результат, но я не знаю, какой из них может быть быстрее, он должен быть отмечен на стенде.

Но в случае linq2sql я предпочитаю коррелированный подзапрос вместо join, потому что в настоящее время, если вы хотите проверить уравнение два элемента, вы должны использовать синтаксис:

 new {X,Y} equals new {X',Y'}
 

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

Ответ №4:

Чтобы добавить третий и более предпочтительный метод в смесь с LINQ to SQL, используйте ассоциации между таблицами (даже если они не настроены в вашей базе данных). С этим вы можете перемещаться по графу объектов, а не использовать соединения:

 var query = from cu in Customer 
              from ad in cu.Addresses 
              select ad; 
 

Примечание: при запросе графов объектов LINQ to SQL преобразует соединение в левое внешнее соединение, где-поскольку синтаксис join / where по умолчанию является внутренним соединением.

Соединения в LINQ следует использовать, когда между объектами нет естественной связи. Например, используйте join, если вы хотите увидеть список магазинов, которые находятся в том же городе, что и ваши клиенты. (Присоединиться к клиенту.Адрес.Город с хранилищем.Адрес.Город).

Ответ №5:

Между этими двумя запросами не должно быть разницы. На самом деле я сам задавался этим вопросом несколько месяцев назад. Я проверил это через LINQPad. Это бесплатный инструмент, который вы можете скачать и фактически увидеть сгенерированный SQL любого запроса LINQ (это запрос, который отправляется в базу данных).

Сгенерированный SQL должен быть одинаковым для этих двух запросов.

Если вы делаете это через Visual Studio, есть также способ просмотреть сгенерированный SQL.

Комментарии:

1. К вашему сведению, для LINQ to SQL, чтобы увидеть сгенерированный SQL, просто вызовите . toString в запросе.