你会允许这种类型的查询吗？

我正在探索在我们的开发工作室中使用ORM工具，特别是Entity Framework 4.0。由于我们使用非常大的数据库，因此我对它产生的查询有点担心。你会允许这种类型的查询吗？

做一些简单的事情，比如在一个状态下获取客户端地址如下所示。

作为数据库开发人员或管理员，你会允许这么做吗？它看起来很糟吗？假设每个连接都在聚簇索引上。

SELECT 
[Project2].[ClientKey] AS [ClientKey], 
[Project2].[FirstName] AS [FirstName], 
[Project2].[LastName] AS [LastName], 
[Project2].[IsEnabled] AS [IsEnabled], 
[Project2].[ChangeUser] AS [ChangeUser], 
[Project2].[ChangeDate] AS [ChangeDate], 
[Project2].[C1] AS [C1], 
[Project2].[AddressKey] AS [AddressKey], 
[Project2].[ClientKey1] AS [ClientKey1], 
[Project2].[AddressTypeCode] AS [AddressTypeCode], 
[Project2].[PrimaryAddress] AS [PrimaryAddress], 
[Project2].[AddressLine1] AS [AddressLine1], 
[Project2].[AddressLine2] AS [AddressLine2], 
[Project2].[City] AS [City], 
[Project2].[State] AS [State], 
[Project2].[ZIP] AS [ZIP] 
FROM (SELECT 
    [Distinct1].[ClientKey] AS [ClientKey], 
    [Distinct1].[FirstName] AS [FirstName], 
    [Distinct1].[LastName] AS [LastName], 
    [Distinct1].[IsEnabled] AS [IsEnabled], 
    [Distinct1].[ChangeUser] AS [ChangeUser], 
    [Distinct1].[ChangeDate] AS [ChangeDate], 
    [Extent3].[AddressKey] AS [AddressKey], 
    [Extent3].[ClientKey] AS [ClientKey1], 
    [Extent3].[AddressTypeCode] AS [AddressTypeCode], 
    [Extent3].[PrimaryAddress] AS [PrimaryAddress], 
    [Extent3].[AddressLine1] AS [AddressLine1], 
    [Extent3].[AddressLine2] AS [AddressLine2], 
    [Extent3].[City] AS [City], 
    [Extent3].[State] AS [State], 
    [Extent3].[ZIP] AS [ZIP], 
    CASE WHEN ([Extent3].[AddressKey] IS NULL) THEN CAST(NULL AS int) ELSE 1 END AS [C1] 
    FROM (SELECT DISTINCT 
     [Extent1].[ClientKey] AS [ClientKey], 
     [Extent1].[FirstName] AS [FirstName], 
     [Extent1].[LastName] AS [LastName], 
     [Extent1].[IsEnabled] AS [IsEnabled], 
     [Extent1].[ChangeUser] AS [ChangeUser], 
     [Extent1].[ChangeDate] AS [ChangeDate] 
     FROM [Common].[Clients] AS [Extent1] 
     INNER JOIN [Common].[ClientAddresses] AS [Extent2] ON [Extent1].[ClientKey] = [Extent2].[ClientKey] 
     WHERE ((CAST(CHARINDEX(UPPER('D'), UPPER([Extent1].[LastName])) AS int)) > 0) AND ([Extent1].[IsEnabled] = 1) AND ([Extent2].[City] IS NOT NULL) AND ((UPPER([Extent2].[City])) = (UPPER('Colorado Springs')))) AS [Distinct1] 
    LEFT OUTER JOIN [Common].[ClientAddresses] AS [Extent3] ON [Distinct1].[ClientKey] = [Extent3].[ClientKey] 
) AS [Project2] 
ORDER BY [Project2].[ClientKey] ASC, [Project2].[FirstName] ASC, [Project2].[LastName] ASC, [Project2].[IsEnabled] ASC, [Project2].[ChangeUser] ASC, [Project2].[ChangeDate] ASC, [Project2].[C1] ASC

来源

2011-01-10 William

它是ORM生成这些查询，还是查询某些C＃语句的写入方式的结果？ UPPER（）的存在使我相信后者...... – 2011-01-10 01:24:28

这是由什么产生的LINQ查询？ – 2011-01-10 02:53:17

内连接地址的客户端...

INNER JOIN [Common].[ClientAddresses] AS [Extent2] 
    ON [Extent1].[ClientKey] = [Extent2].[ClientKey]

与城市条件...

AND ((UPPER([Extent2].[City])) = (UPPER('Colorado Springs')))

现在左侧再次加入地址？

LEFT OUTER JOIN [Common].[ClientAddresses] AS [Extent3] 
    ON [Distinct1].[ClientKey] = [Extent3].[ClientKey]

左连接是多余的，因为行必须已经存在以符合条件。

而且它是在内部查询这可能是不必要的，如果表是标准化

我不相信的ORM生成优化的查询选择不同的行。

来源

2011-01-10 01:06:22

似乎有一个不必要的派生表，它几乎使查询长度加倍。它不太可能对运行时间性能产生显着影响，所以不值得担心。

从性能角度来看，更麻烦的是在WHERE子句中使用函数来防止使用索引。

WHERE ... 
AND ((UPPER([Extent2].[City])) = (UPPER('Colorado Springs')))

这应该只是这个用适当的区分大小写排序：

WHERE ... 
AND [Extent2].[City] = 'Colorado Springs'

但它可能不会在实践中的一个问题。

来源

2011-01-10 00:37:11

你会允许这种类型的查询吗？

回答

相关问题