是否有必要在 Linq 中使用连接到 Sql

Is it necessary to use joins in Linq to Sql

我今天正在练习,当我意识到 linq to sql 可以通过两种方式从数据库中检索数据时,我创建了两个数据网格并使用两种不同的方式来填充这些数据网格中的每一个,它们产生了同样的结果。

第一种方法是使用joins从相关表​​中获取数据,另一种方法是使用类似object的linq查询来访问相关表。代码如下:

NorthWindDataContext dbContext = new NorthWindDataContext();

        var orders = from ord in dbContext.Orders
                     select new { ord.ShipCountry , ord.Customer.ContactName};

        var orders2 = from ord in dbContext.Orders
                     join cust in dbContext.Customers on ord.CustomerID equals cust.CustomerID
                     select new
                     {
                         ord.ShipCountry, cust.ContactName
                     };
        var data = orders2;

        DataGrid.ItemsSource= orders;
        DataGrid2.ItemsSource = orders2;

我和标题一样的问题是,是否完全有必要使用joins,因为我发现它们有时使用起来真的很麻烦。

答案是“有点”。由于您使用的是诸如 Linq-to-Sql 之类的 ORM,因此您不需要直接在 linq 查询中调用 join 来完成您想要做的事情。

但是,当 ORM 激活查询时,它会生成实际的 SQL 代码,其中包含一个连接语句以获取您正在查询的结果。由于您使用的是 ORM,因此返回的数据被映射到对象,并且由于 Customer 在对象之间存在关系,因此该关系也将从数据库转换为对象。

ord.Customer.ContactName

上面的语句很可能被转换为在客户和订单之间执行 INNER JOIN 的 JOIN 语句。

因此,您的两个 LINQ 查询很可能生成相似的 SQL 查询。两者都有一个 JOIN 语句。因为您的对象之间的关系也存在于数据库中(并且所有内容都映射在一起以显示这种关系)您不需要直接在 LINQ 语句中使用连接。

您需要使用能够让您从订单到客户的东西。

Join可以做到这一点。这就是第二个查询的工作方式。

拥有order"know"关于customer可以做到这一点。这就是第一个查询的工作原理。

如果您的数据提供者知道 ordercustomer 之间的联系,那么它们将是一回事。

如果您的数据提供者不知道该连接,那么第一个示例中的方法将导致 N + 1 次查找而不是 1 次。

只要存在适当的关系标记属性(这正是 Linq2SQL、EF、NHibernate 等之间的区别),对 linq 友好的 ORM 通常会知道这些连接。

了解 join 方法对于提供者不知道关系或者您有理由加入外键关系以外的其他关系的情况仍然很重要。