通过业务逻辑(c#)来处理(sql)会提高性能吗？

Question

我们正在研究一种算法，它计算出通过可变路由将资源从多个点移动到X点的最佳方法，过程如下所示：

1)获取所有可能的路由(DB命中以获取解决方案中涉及的所有路由)

2)获取所有可能的起点

3)构建一个综合所有路由的双向图。

4)用Hoffman Pavley算法计算k-最短路径(我们将其限制在一定数目的路径ei:前10条最短路径)

-为实际起点-预见路径

5)评估路由，计算从每个路由节点到目的地可以携带多少资源。

6)根据每个点移动的资源数量以及该解决方案所涉及的移动和转运(将资源从一种运输转移到另一种运输)的数量来分配标点符号。

-实际起点的前端路径

7)返回标点符号排序的可定位解。

这个逻辑的第一个版本用了1分钟来计算解。但是在第二次修订时，我们发现我们有很多SelectN+1问题，所以我们优化了查询(不是所有查询)，现在每次运行都需要3-10秒，这取决于变量的数量。

但现在有人建议通过所有这些逻辑来处理SQL，并让SQL server来处理所有的计算，他说，由于所有数据都在Server上，数据库完成所有计算所需的时间将减少，从而避免了所有选择N+1和延迟加载的问题。此外，他还担心并发性，运行这种逻辑的多个用户将导致应用服务器瘫痪，但他表示，sql-server能够很好地处理此类负载。

我的观点是:在尝试传递1500行c#逻辑到Transact SQL之前，也许我们应该尝试优化所有查询。更不用说，对于某些计算，我们使用第三方库进行双向图和Hoffman算法，这些算法在事务处理中是不可用的，或者我们需要寻找在事务中已经写好的其他东西，或者实现我们所有的逻辑本身。

注意:我们使用Nhibernate作为ORM。

Answer 1

将逻辑迁移到SQL可能有帮助，但它有代价：

维护与1500行etc.)

• Debugging代码相同的SQL的
• (100行查询，添加了新特性后过时的存储过程)是一个真正的地狱(

)。

因此，我的观点是，在将所有逻辑迁移到数据库之前，您应该尝试优化查询。

Answer 2

我只会考虑将逻辑移到数据库作为最后的手段。

• 一个很好的指南是在数据库中保持基于集的处理，并在应用程序中进行迭代处理。您已经有了许多foreach语句，除非它们可以被压缩为set操作，否则在数据库世界中您将真正受到影响。如果这是业务规则的应用程序，那么它应该在应用程序层中，除非有理由将其放在数据库中。
• 需要很长时间才能将您的1500行代码移植到TSQL。如果这是MSSQL的最新版本，您可以使用.NET CLR，但根据我的经验，在Windows
• 上比.NET慢得多，应该相对简单地将所有所需数据提前提取，以避免N+1选择；获取所需的一切，并将其加入到适当的对象图中。

最后，似乎对所有请求都复制了前4个步骤。选择所有数据并处理前四个步骤，然后将图保存在内存中，这样做可能是有意义的，这样就避免了为每个请求检索和预处理所有数据所带来的先入为主的影响。这可能是不可能的，但将完全消除数据检索问题。

Answer 3

交易是这样的：

将逻辑转移到数据库通常会提高复杂报表需求(如您的报表)的性能。这是通过对数据进行更好的索引来实现的，因此索引意味着大部分工作(即:排序)都是在插入时为您完成的。

由于排序工作是在您需要的索引的插入时间完成的，所以您最终会遇到较慢的插入和其他写操作。对于一个需要做的不仅仅是你的报告的系统来说，这往往是有害的。

此外，在某些时候，你会想要考虑你的应用程序的规模。当您这样做时，请考虑您的数据库服务器可能已经是您最昂贵的服务器，以及升级成本最高的服务器。单是许可费用就会使您的数据库服务器升级变得不太适合您的预算管理器。数据库通常也更难在集群中工作。与数据库相比，添加web或应用服务器并让它们在农场工作是在公园里散步。由于这些原因，你可以做的任何事情，释放你的数据库的性能压力，很可能会改善你的应用程序的扩展方式。