业务逻辑到存储过程 - 仍然困惑

我看了很多关于articles为什么我们不应该有几个地方的业务逻辑，但尽量保持它在BLL代码。我明白易于维护的重点，并且更清楚地了解代码的功能。业务逻辑到存储过程 - 仍然困惑

但是，我从来没有发现申请（重复）的一些商业规则，存储过程会显著减少数据库客户端应用程序的数据传输时的情况下我们应该怎样做任何解释？

例如，我目前正在OS在一段较长时期的一些statiscal数据显示。目前所有的商业逻辑/规则都在商业逻辑层（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

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

那么，什么是推荐的方式吗？而为什么？

来源

2014-05-21 Goran

也许你仍然可以有业务逻辑，它属于这东西归类为多个“计算”？

无论哪种方式，你有一个令人信服的理由这样做计算在数据库层，当你在一百万加行。所以我会继续计算功能。所以，在你的例子可重复使用的功能将使用类似：

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（或计算列）将提供计算所在的一个位置。

来源

2014-05-21 01:31:54 JBrooks

业务逻辑到存储过程 - 仍然困惑

回答

相关问题