将业务逻辑转换为存储过程 - 仍然很困惑答案

【问题标题】：Business logic into stored procedure - still confused将业务逻辑转换为存储过程 - 仍然很困惑
【发布时间】：2014-07-09 10:49:24
【问题描述】：

我读过很多articles，关于为什么我们不应该在几个地方有业务逻辑，而是尽量将它保存在 BLL 代码中。我理解易于维护的要点，并且更清楚地了解代码的作用。

但是，我从来没有找到任何解释，如果将某些业务规则应用于（重复）存储过程会显着减少从数据库到客户端应用程序的数据传输，我们应该怎么做？

例如，我目前正在处理一些较长时间的统计数据表示。目前所有的业务逻辑/规则都在业务逻辑层（dll）中。用户可以选择在一年的月份级别上显示一些结果。这意味着，如果我不在存储过程中使用业务规则，我将需要返回大约 1,000,000 条记录，然后在客户端将业务规则应用于这些记录。但是，如果我将业务规则应用于存储过程，那么它会将返回的记录数减少到 12。

应用业务规则的示例如下所示：

 AVG(CASE WHEN Field1 IS NULL
               THEN CASE WHEN c.Field2 = 1
               THEN ( cap1.Field3 / cap1.Field4) * 60
               ELSE CASE
 ..... etc

所以这不是一个简单的逻辑，而是一个复杂的逻辑。而且由于这种逻辑可以在许多不同的存储过程中重复，这将是数据库中单独函数的候选者，以避免重复代码。

那么，这里推荐的方式是什么？ 为什么？

【问题讨论】：

标签： stored-procedures business-logic-layer

【解决方案1】：

也许您仍然可以在其所属的位置保留业务逻辑并将这些内容归类为更多“计算”？

无论哪种方式，当您拥有超过一百万行时，您都有充分的理由在数据库层进行计算。所以我会把计算保留在函数中。因此，在您的示例中，将使用可重用函数，例如：

SELECT AVG(dbo.fnFieldsEvaluate(Field1, Field2, Field3, Field5)) as FieldAvgs,
...

或者如果用的比较多，足够简单，只依赖单行的列，表中的计算列会更方便。

   CREATE TABLE dbo.Products 
   (Field1 ....,
    Field2 ....,
    RowEvaluatesTo AS CASE WHEN Field1 IS NULL
               THEN CASE WHEN Field2 = 1
               THEN(Field3 / Field4) * 60
               ELSE CASE ...

您的函数 dbo.fnFieldsEvaluat（或计算列）将提供该计算所在的一个位置。

【讨论】：