ege*_*ari 2 sql database performance reporting
我写了一些相当复杂的报道.其中一些......我不确定如何只为其中一个值编写SQL查询,更不用说在一个查询中填充它们了.
通过代码来提取数据并通过代码来解决所有问题是否常见？或者我应该尝试找到一种方法来使所有报告依赖于sql？
我有一个非常丰富的域模型.实际上,可以扩展部分代码以准确计算他们想要的内容.实际的逻辑并不是那么难写 - 而且使用我的域模型比使用SQL更好.使用SQL,编写业务逻辑,重构它,测试它并将其置于版本控制是一种巨大的痛苦,因为它与您的实际代码是分开的.
例如,他们想要的统计数据是他们改善了多少,特别是与同一班级,同一所学校的其他人相比,与其他学校相比.这需要对他们过去如何执行最新信息进行一些非常详细的分析,并对您要比较的群体进行整体计算.我甚至无法想象sql查询甚至会是什么样子.
问题是,这个%改进不是数据库中的一个列 - 它通过实时分析所有实时数据来进行大量计算.没有办法将这些数据缓存在一列中,因为每次学生做某事时都需要对每一行进行计算,这是疯狂的.
我有点害怕提取数百条记录以获得这些数字.我可能不得不抽出那么多只是为1个用户计算1个值......如果他们想要在一个屏幕上为所有用户提供报告,那么它基本上会分析整个数据库.而这只是报告中他们想要的许多列的一列值!
基本上,无论我选择何种方式编写报告,他们想要的报告都是一次巨大的表现.
无论如何,我想问你用什么样的解决方案来解决这些问题.
有时,可以通过单个查询生成报告.有时必须编写一些程序代码.有时,即使可以使用单个查询,编写一些过程代码也要好得多,更快/更清楚.
一个典型的例子 - 另一位开发人员写了一篇使用单个查询的报告.这个问题令人惊讶 - 将一张桌子转向一边,做了一些惊人的总结 - 并且很可能通过超空间管理输出 - 真正的艺术品.我甚至没有想过做这样的事情,只是通过准备就能学到很多东西.唯一的问题是它需要45分钟才能运行并使系统陷入困境.我很喜欢这个问题...但最终......我承认 - 我把它杀死了.((呜咽))我用电锯肢解它,同时哼着"高速公路到地狱"!我...我写了一些程序代码来掩盖我的曲目......没有人注意到.我想说我很抱歉,但......最终这项工作在30秒内完成.哦,当然,很容易说"但性能很重要,你好"
上述观点是"让事情尽可能简单,但不要简单".如果你发现自己的查询覆盖了三个页面(我喜欢这个查询,但是......)也许它会试图告诉你一些事情.一个更简单的查询和一些过程代码可能会在页面方面占用相同的空间,但可能更容易理解和维护.
分享和享受.