LINQ 无疑简化了数据库编程，但它有缺点吗？内联 SQL 需要以某种方式与数据库通信，从而打开数据库以进行注入。内联 SQL 还必须进行语法检查，构建计划，然后执行，这需要宝贵的周期。在优秀的数据库应用程序编程中，存储过程也是一个坚如磐石的标准。我认识的许多程序员都使用简化开发的数据层，但是并没有达到 LINQ 的程度。是时候放弃 SP 转而使用 LINQ 了吗？
Mike
问问题
6086 次
7 回答
6
LINQ to SQL 实际上在数据库中存在一些令人担忧的性能问题。基本上，它会根据您使用的参数的长度创建多个执行计划。我不久前在我的博客LINQ to SQL 上发布过它可能会导致性能问题。
现在，是不是说 LINQ 没有一席之地？几乎不。LINQ 在开发工具包中肯定有一席之地，就像存储过程一样。最终，您希望在绝对需要性能时使用存储过程，并在任何其他情况下使用 ORM 工具。
就内联 SQL 而言，有多种方法可以执行内联 SQL，以便计划只构建一次并且永远不会重新编译。大多数 ORM 也应该注意性能调整的这一方面，并且使用这些方法通常是执行 SQL 的最安全方法，因为它会强制您使用参数化查询。
与大多数数据库解决方案一样，正确答案取决于您要解决的问题。如果您更喜欢开发速度而不是数据库/应用程序性能，那么使用 LINQ 或其他 DAL/ORM 工具是最好的选择。如果您更喜欢性能而不是易于开发，那么使用存储过程和纯数据集将是您最好的选择。LLBLGen 甚至提供了一个 LINQ to LLBLGen 层，因此您可以使用 LINQ 查询 LLBLGen 的对象，并让 LLBLGen 实际处理构建您的查询并避免 LINQ 的一些缺陷。
于 2008-09-16T15:48:57.027 回答
3
你的基本前提是有缺陷的..
内联 SQL 需要以某种方式与数据库通信，从而打开数据库以进行注入。
不，它没有。将用户输入的值硬编码到 SQL 语句中可以，但您也可以使用存储过程来实现。
参数化查询可以防止注入攻击，但内联 SQL 可以像存储过程一样轻松地进行参数化。
内联 SQL 还必须经过语法检查，构建计划，然后执行。
所有 Sql（SP 和内联）都必须经过语法检查，并在第一次调用时制定计划。此后，请求和执行计划的确切文本被缓存。如果收到另一个具有完全相同文本（不计算参数）的请求，则使用缓存的执行计划。
因此，如果您将值硬编码到内联 SQL 中，文本将不匹配，并且必须重新解析查询。但是，如果您使用参数，则查询的文本将匹配，并且您将获得缓存命中。在这种情况下，查询是内联 SQL 还是 SP 无关紧要。
换句话说，内联 SQL 的唯一问题是很容易做一些缓慢且不安全的事情。但是使内联 SQL 快速且安全不再是使用 SP 的工作。
这将我们带到了 LINQ，它始终使用参数，即使您将值硬编码到 LINQ 语句中，也使“快速和安全”的内联 SQL 变得微不足道。
与 SP 相比，LINQ 还具有将所有代码集中在一个位置的优势，而不是分散在两台不同的机器上。
于 2008-09-16T17:42:20.497 回答
2
如果您对基准测试感兴趣，Rico Mariani 有一个出色的 5 部分研究，涵盖了定性和定量差异。
他可能是一名 MS 专家，但他被称为性能狂人 - 他的基准测试非常全面且经过深思熟虑。
于 2008-09-16T13:41:20.857 回答
1
这是马克西米利安·贝勒（Maximilian Beller）的表演。据他说，LINQ 要慢得多。 阅读他的综合研究
于 2008-09-16T13:33:26.073 回答
1
只需考虑更改列名称 - 现在更改 (n)SP 和 (x)Views。
在数据库上做所有昂贵的事情（如搜索、排序等），你不会注意到问题。
此外，如果您想在不分页的情况下显示大网格......然后使用数据集 - 那个更快。
StackOverflow 也使用 linq2sql - 你看到问题了吗 :) ？
使用 ORM - 这是大多数应用程序的方式。
PS：另外，关于微基准测试——比如..让我们用 ORM 选择 10.000 行——不要这样做。这不是你使用 ORM 的原因。如果要选择 10.000 行，请使用 ADO。
于 2008-09-16T14:29:04.300 回答
0
这取决于你在做什么。LINQ 在实际数据/集操作方面的效率将低于真实数据库。但是您不必通过网络连接到数据库会节省很多。
如果您的数据库在同一台机器上或正式“连接良好”，那么您最好使用它。
但是，如果您要从远程数据库返回一个大型结果集，这可能意味着大量的传输时间，或者如果它是一个非常短的查询，不能证明开销是合理的，那么 LINQ 可能会更好。
于 2008-09-16T13:41:02.997 回答
0
由于 LINQ to SQL 的结构，它不可能比使用原始 SQL更快，无论是您自己的格式良好的查询还是作为存储过程。LINQ 为您带来的不是速度，而是类型安全和组织；简而言之，ORM 通常授予您的大部分好处。
LINQ to SQL 不是关于速度，而是关于构建一个更易于维护的软件系统。这是关于软件工程师和架构师关心的所有东西，比如松散耦合和分层
这并不是说您不能使用 LINQ 构建一些真正无法维护的代码——没有人阻止您自毁前程，但您自己——但是如果做得好，LINQ 可以提供极大的帮助。然而，我并不是说 LINQ 是灵丹妙药。它有许多问题使其难以在许多企业情况下使用——这就是 MS 提供实体框架 (ADO.NET 3.0) 的原因。当然，考虑到最近 EF 的不信任投票，即使这样也不完美。
LINQ to SQL 甚至 EF 是否比原始 SQL 更好？我会说一个响亮的地狱是的。还有其他可能效果更好的解决方案吗？也许。
于 2008-09-16T15:23:19.910 回答