一个开放性的问题可能没有“正确”的答案，但对此的专家意见将不胜感激。
SQL查询是否需要复杂？
从Web Dev的角度来看，随着C＃/ .Net的发展，似乎有很多简单的方法（LINQ，Generics）可以做很多人在SQL查询中做的事情（排序，订购，合并等）。话虽如此，由于SQL往往是许多应用程序的处理“瓶颈”，因此SQL查询的许多逻辑正被转移到业务层。
随着这种趋势的继续，我发现对大型SQL查询的需求减少了。
你们都在想什么？你还在写大型SQL查询吗？如果是这样，是因为你需要或因为你比在业务层工作更舒服吗？
答案 0 :(得分：5)
什么是“大”查询？
IME遇到的“瓶颈”通常是因为这些表的建模很差，而且有人构建了几乎没有SQL经验的SQL查询（最常见的问题是认为SQL实际上是基于SET的程序）。缺乏索引是下一个最常见的问题。
ORM已发展为支持本机查询 - 明确认识到ORM简化了数据库交互，但无法正常执行SQL查询。
通过希望数据库独立性（存在性能风险）来保持业务层中的持久性处理是合理的。否则，忽略数据库可以在更大的负载中处理中心位置（可以聚类）的资金和资源是浪费。
答案 1 :(得分：3)
完全取决于处理。如果你试图在你的SQL中做很多疯狂的东西，它们做了诸如旋转或文本处理之类的东西，或者其他什么东西，并且结果是更快地避免在SQL中执行它并在数据库服务器之外处理它，那么是，你可能使用SQL错了，代码属于业务层或客户端。
相比之下，SQL在集合操作方面表现优异，而且这应该主要用于它。我已经看到很多应用程序放慢了速度，因为业务逻辑或显示代码从数据库中抓取了一百万行结果集，一次一个地返回，然后通过执行有效的设置操作抛出990,000个（JOIN，无论如何）在数据库之外，而不是使用服务器上的查询选择10,000个有趣的结果，然后处理结果。
因此。这取决于“大型SQL查询”的含义。我觉得从你提出这个问题的方式来看，你的意思是“过度复杂的，基于非集合的业务/表示逻辑到SQL查询的翻译，这些翻译本来就不应该编写。”
答案 2 :(得分：2)
在许多数据输入/数据输出情况下，没有。
在某些情况下，是的。
如果你需要处理的只是一个简单的导航层次结构（主要关注父母，兄弟，孩子等），那么LINQ和它的朋友是很好的选择 - 它们减少了大多数人的痛苦（以及努力和风险）查询。但是有很多情况它不能很好地运作：
ROW_NUMBER()等），IO统计数据仅下降到生成查询的5％。答案 3 :(得分：1)
这是一个主观问题。
IMO，SQL（或用于访问数据库的任何查询语言）应该像解决性能问题一样复杂。
有两个相互竞争的利益：
效果：这意味着，在最少量的查询中加载您需要的最少量数据。
可维护性：使用最简单，最可重复使用的查询来尽可能多地加载（比如说，有意义），并在内存中执行其他操作。
因此，您始终需要在性能和可维护性之间找到自己的方法。这实际上没什么特别的 - 这就是你在编程时所做的事情。
在这种情况下，执行数据库查询的新方法不会发生很大变化。即使您使用NHibernate的HQL，也要考虑性能和可维护性。您已经迈出了可维护性的一步，但您可能会回退到SQL来调整一些查询。
答案 4 :(得分：0)
对我来说，编写一个巨大的SQL查询或一堆简单查询然后在代码中执行所有操作之间的决定因素通常是性能。后者是首选，但如果它太慢，我会做前者（毕竟Sql针对数据处理进行了优化）。
之所以我更喜欢后者是因为我的团队通常更喜欢使用代码进行SQL查询。我喜欢sql但是如果一个巨大的SQL查询意味着我只能在合理的时间内调试/理解它，那不是一件好事。另一个原因是，通过巨型查询，您通常会在其中编写一些业务逻辑。如果我有一个业务层，我更喜欢尽可能多的业务逻辑。
当然，您可以决定将所有业务逻辑填充到存储过程中。您的程序只不过是数据库API的GUI界面。这取决于项目的要求以及您的团队是否可以处理此问题。
那就是说，你将Linq作为替代技术。我在团队中注意到，由于我对SQL的经验，我对Linq非常满意，而我的同事却没有。更深层次的问题是程序性与基于集合的思维。 Linq可与sql相媲美。如果你对SQL不熟悉，很可能你不会使用Linq。