c# - 将业务逻辑(c#)传递给事务处理(sql)会提高性能吗？

Question

我们正在研究一种算法，计算通过可变路线将资源从多个点移动到点 X 的最佳方式，过程如下:

1) 获取所有可能的路径(DB hit 获取解中涉及的所有路径)

2)获取所有可能的起点

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

-----foreach starting point----

4) 使用 Hoffman Pavley 算法计算 k 条最短路径(我们将此限制为一定数量的路径 ei:前 10 条最短路径)

-----foreach path for the actual starting point-----

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

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

-----END foreach path for the actual starting point-----

-----END foreach starting point----

7) 返回按标点排序的可能解

此逻辑的第一个版本用了大约 1 分钟的时间来计算解决方案。但在第二次修订中，我们发现我们遇到了很多 Select N+1 问题，因此我们优化了查询(不是所有查询)，现在每次运行大约需要 3-10 秒，具体取决于变量的数量。

但现在有人建议将所有逻辑传递给 SQL Server，让 SQL Server 处理所有计算，他说因为所有数据都已经在 SQL Server 上，所以数据库完成所有计算所需的时间会更少避免所有选择 N+1 和延迟加载问题。他还担心并发性，多个用户运行此逻辑会导致应用程序服务器崩溃，但他说 sql-server 可以很好地处理这种负载。

我的意见:也许我们应该在尝试将 1500 行 c# 逻辑传递给 Transact SQL 之前尝试优化所有查询。更不用说对于某些计算，我们正在为双向图和 Hoffman Pavley 算法使用第三方库，这些库在 transact 中不可用，我们要么需要寻找已经在 transact 中编写的其他内容，要么自己实现所有逻辑。

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

Answer 1

将逻辑转移到 SQL 可能会有所帮助，但它有代价:

• 维护与 1500 行 C# 代码相同的事情的 SQL 是一个真正的 hell (100 行查询、添加新功能后变得过时的存储过程等)
• 调试要复杂得多

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