存储过程的业务逻辑

Question

我正在使用存储过程来访问我的数据库数据。我试图将业务逻辑放在代码中而不是存储过程中。但是我有一个案例我不知道如何解决：

我有一张类似Items(item_id, itemd_name, item_price) 的表格，里面有 700 个项目。

现在我想向客户端显示所有项目及其名称。 由于我为 Web 开发，我不想加载所有 700 项，而是使用分页 - 一次 40 项。

（当我写“加载”时，我的意思是存储过程返回数据表，我编写的代码将每一行转换为一个项目类 - 这就是我不想加载 700 个项目的原因，它会处理很多数据我真的不需要）

所以我编写了知道获取 40 项的存储过程。

现在，我需要汇总所有商品的价格并加上 16% 的税。

问题是我无法使用从该商店过程中获得的 40 件商品，因为我需要汇总所有 700 件商品的价格和税金。

我找到的唯一解决方案是使用另一个存储过程，该过程将返回价格+税金的总和。

Answer 1

基本上，您使用两个不同的存储过程来满足两个不同（尽管是连接的）业务需求，这在我的书中是可以的。

第一个是：显示具有给定偏移量和页面大小的数据页面。 第二个是：按照一定的规则显示一个数据汇总。

如果您使用仅获取所有数据的简单存储过程，并且您可以在应用程序端处理分页和汇总，那么两者都可以完成，这将遵守您的“数据库中没有逻辑”规则。当您有 700 行时，这不是什么大问题，但是，如果这个数字达到数十万，您将在加载和处理大量您并不真正需要的项目时遭受很大的性能损失。

第二种方法是将分页逻辑放在一个 proc 中，而将汇总逻辑放在另一个中。分页逻辑非常通用，因此不必将其视为“业务”，但摘要生成为了有用，必须包含真实的业务逻辑。这在性能方面可行，但显然违反了您的规则。

当然，没有一个正确的答案，但在大多数情况下，我不介意将业务逻辑放在数据库中，因为，即使是数据库的结构也受到系统业务规则的限制。如果我们绝对想要“数据库中没有业务规则”，我们应该放弃默认值、检查约束等，因为它们也是对数据的业务限制，而不是数据本身的属性。