数据库是否触发了使用此业务逻辑的方式

我目前在我的应用程序中实现了一些汇总从数据库中获取的大量信息的“报告”：表中的每个单元格都来自另一个表格的总数，每个单元格来自于另一个表格的总数等。
报告应该始终向用户显示最新的数据：每个数据在软件中的任何位置更改并且报告必须是最新的。数据库是否触发了使用此业务逻辑的方式

我最终生成了太多的SQL。

我试图缓存（在数据库中）中间结果和表，它的工作原理。但是，在应用程序中可以更改数据的任何地方，我必须重新计算在太多地方调用以recomputeCache()调用结束的缓存（请记住，这是为了保持绝对最新的报告）。

DBMS的触发器可以工作：对表计算下一个，它拥有一个触发计算下一触发等01 但我怕的触发器：

什么复杂性？进行计算的代码非常庞大且“聪明”：200行.NET语言加糖将变成500个PL/SQL。
可维护性如何？ PL/SQL是不是很难找到，阅读，理解，修改，调试等？
业务逻辑封装怎么样？这个计算不应该属于业务逻辑层吗？

我正在听任何意见，帮助我“典型”软件缓存之间进行选择（我会尽力找到一个智能高速缓存重新计算战略），并触发基于表重新计算（也许牺牲了软件的最佳实践和可维护性？）...

谢谢！

来源

2012-11-14 Clément

你可以在自动更新中使用物化视图吗？ –

为了您的报告，我会先尝试使用视图。该视图将始终处于最新状态，因为它只是查看基础表的最新数据的视图。这将为您节省复杂性以及与您指出的触发相关的一些令人头痛的问题。

例子：

CREATE VIEW report AS 
SELECT 'sales' AS name, (SELECT sum(sales) FROM sales) AS value 
UNION ALL 
SELECT 'expenses' AS name, (SELECT sum(expenses) FROM expenses) AS value

如果视图的性能不够充分，那么你确实可以考虑触发器和大约合计总额，而不必重新读取所有记录聪明。但是我会首先从最简单的选项开始。

来源

2012-11-14 18:54:07 Zugwalt

定义视图的查询每次执行都太长，但正如Vaibhav Desai所说，物化视图可以解决这个问题。但是，要聚合的数据量非常大，我不知道是否可以将它作为单个SQL查询编写。我会深入研究，谢谢。 –

数据库是否触发了使用此业务逻辑的方式

回答

相关问题