LINQ To SQL是否提供比使用ado.net和oledb更快的响应时间？ [英] Does LINQ To SQL provide faster response times than using ado.net and oledb?

问题描述

LINQ简化数据库编程毫无疑问，但它有一个缺点吗？内联SQL需要一个以特定方式与数据库通信，以便将数据库打开以进行注入。内联SQL也必须进行语法检查，制定计划，然后执行，这需要宝贵的周期。存储过程在伟大的数据库应用程序编程中也是一个坚实的标准。许多程序员我知道使用一个数据层，简化了开发，但是，不在LINQ的程度。是时候放弃SP上的LINQ吗？

LINQ simplifies database programming no doubt, but does it have a downside? Inline SQL requires one to communicate with the database in a certain way that opens the database to injections. Inline SQL must also be syntax-checked, have a plan built, and then executed, which takes precious cycles. Stored procedures have also been a rock-solid standard in great database application programming. Many programmers I know use a data layer that simplifies development, however, not to the extent LINQ does. Is it time to give up on the SP's and go LINQ?

推荐答案

LINQ to SQL实际上在数据库中提供了一些令人担忧的性能问题。基本上，它会根据您使用的参数的长度创建多个执行计划。我在我的博客上发布了一段时间了 LINQ to SQL可能会导致性能问题。

LINQ to SQL actually presents some alarming performance problems in the database. Basically, it creates multiple execution plans based on the length of the parameter you are using. I posted about it a while back on my blog LINQ to SQL may cause performance problems.

现在，是说LINQ没有地方吗？几乎不。 LINQ肯定在开发工具包中有一个地方，就像存储过程一样。最终，当性能是绝对必要的时候，你想使用存储过程，在任何其他情况下使用ORM工具。

Now, is that to say that LINQ doesn't have a place? Hardly. LINQ definitely has a place in the development toolkit, just like stored procedures. Ultimately, you want to use stored procedures when performance is absolutely necessary and use an ORM tool in any other situation.

就内联SQL而言，内联SQL，以便计划只构建一次，不会重新编译。大多数ORM也应该关注性能调优的这一方面，并​​且使用这些方法通常是执行SQL的最安全的方法，因为它迫使您使用参数化查询。

As far as inline SQL goes, there are ways to execute inline SQL so that the plan is only built once and is never recompiled. Most ORMs should take care of this aspect of performance tuning as well and using these methods is usually the safest way to execute your SQL since it forces you to use parameterized queries.

像大多数数据库解决方案一样，正确的答案取决于您要解决的问题。如果你喜欢开发速度超过数据库/应用程序性能，那么使用LINQ或另一个DAL / ORM工具是最好的方法。如果你喜欢性能超过易于开发，那么使用存储过程和纯数据集将是你最好的选择。 LLBLGen甚至提供了一个LINQ到LLBLGen层，所以你可以使用LINQ查询LLBLGen的对象，并让LLBLGen实际处理构建你的查询，避免一些LINQ的失败。

Like most database solutions, the right answer depends on the problem you're trying to solve. If you favor development speed over database/application performance, then using LINQ or another DAL/ORM tool is the best way to go. If you favor performance over ease of development, then using stored procedures and pure datasets is going to be your best bet. LLBLGen even provides a LINQ to LLBLGen layer so you can use LINQ to query LLBLGen's objects and have LLBLGen actually handle building your queries and avoid some of the downfalls of LINQ.

这篇关于LINQ To SQL是否提供比使用ado.net和oledb更快的响应时间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！