c# - 从 SqlCommand 对象返回一个列表——我怎样才能让数据库尽可能少地工作？

Question

我正在为我的类(class)写一个私有(private)方法。我将一个整数列表作为参数传递给它，代表我的 SQL Server 2008 表中一行的 ID。

我希望返回 List<string>的 "Name" (一列)在其中一个传入的整数等于 "ID" 的所有行上.所以如果我传入 List<int> {1, 2, 3 } .

我想本质上运行命令 (SELECT Name FROM Table WHERE ID = 1 OR ID = 2 OR ID = 3).ToList<string>() .

我正在使用的数据库非常繁忙，因此尽可能优化我的解决方案非常重要。考虑到这一点，我想知道使用 .dbml 文件创建到该数据库的链接并使用 Linq to SQL 查询数据库是否更好？

或者只是创建一个 SQLCommand 对象，执行一次，遍历读取器并将其保存在列表中？执行此操作的最佳方法是什么？正在创建 .dbml 文件来表示非常繁忙的数据库不良做法吗？

Answer 1

创建 .dbml 与服务器端性能关系不大；这改变了调用端的工具——但服务器不会真正注意到来自 .dbml 的命令与手工编码的命令之间的区别，至少:不是这么简单的事情(我应该注意，对于复杂的查询，手工编码查询通常可以胜过机器生成的查询)。

在调用方的性能方面； .dbml 只是一个包装器围绕 所有常用的命令/阅读器/等等——它不能使事情变得更快。在某些情况下，如果它不能很好地解析表达式，或者没有缓存解析的结果(就 TSQL 而言)，它可能会变慢。

不过，我会说的是 dapper将为您很好地处理这个问题:

var ids = new List<int>{1,2,3};
var names = conn.Select<string>("select Name from Table where ID in @ids",
      new {ids}).ToList();

dapper 将发现 in @ids 用法，并将其扩展为参数，执行:

select Name from Table where ID in (@p__0, @p__1, @p__2)

(或类似的东西)- 传递 1、2 和 3 作为这些值。

这给你:

• 来电者方便
• 调用方的性能(dapper 已经过大量优化)
• 全参数化
  • 允许在服务器上优化查询计划重用

更多一般，dapper 也会愉快地处理一般的实体映射，例如:

int id = 12345;
var customer = conn.Select<Customer>("select * from Custom where Id = @id",
    new { id }).Single();