2

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

我有一个像表:Items(item_id, itemd_name, item_price)其中700项。

现在我想显示客户端的所有项目和他们的名字。 由于我为网络开发,我不想加载所有700个项目,但一次使用分页 - 40个项目。当我写“加载”时,我发现存储过程返回数据表,并且我写的代码将每行转换为一个item类 - 这就是为什么我不想加载700个项目,它会处理很多数据我并不需要)

所以我写了存储过程,知道得到40项。

现在,我需要总结所有项目的价格,并将其加入16%的税。

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

我发现的唯一解决方案是使用另一个存储过程,将返回价格+税额总和。

+0

你在什么基础上总结数据?除了当前页面的40个项目之外,您是否也可以获得另一个结果集,其中包含这些项目标识的SUMed值?一旦你有id和他们的聚合 - 你的业务逻辑/税收计算等仍然可以应用在你的应用逻辑,而不是数据库。 – InSane 2010-12-21 08:34:41

回答

2

基本上,您正在使用两种不同的存储过程,用于两种不同(尽管连接)的业务需求,这在我的书中可以。

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

如果您使用一个简单的存储过程来获取所有数据,并且您可以在应用程序端处理分页和总结,并且符合您的“数据库中没有逻辑”规则,则两者都可以完成。当你有700行时,这不会成为问题,但是,如果这个数字增加到几十万,那么你将会在加载和处理大量你并不需要的项目时产生巨大的性能损失。

第二种方法是将分页逻辑放在一个proc中,并在另一个逻辑中进行总结。分页逻辑非常通用,所以它不必被认为是“业务”,但为了有用,汇总生成必须包含真实的业务逻辑。这将工作,表现明智,但显然违反了你的规则。

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