这是一个创建于 2470 天前的主题，其中的信息可能已经有所发展或是发生改变。
产品的一个推荐时间功能：由几条数据根据当前系统配置的参数和 20 多张规则表计算出最优时间
现象：1、由于系统的全局参数配置上 100 个 2、规则表有 20 多张（数据量不大，多的才 100 条） 该功能根据配置的不同，有不同的逻辑处理，且会读取不同的规则表进行一些逻辑运算、查询数据库次数非常多。正常 1 秒中内完成。 如果规则与参数使用的少，完全满足要求。但是如果规则与参数多了，导致有的时候 5 6 秒或者更久才计算出来结果。
考虑：现在感觉不好优化（主要是查询数据库次数非常多、循环也多）。想把该功能放到数据库的存储过程中，会不会得到一个提升。
PS:该功能后续改动量不大（除非要加新规则和参数）
 |
1
xinyewdz 2018-02-26 16:08:05 +08:00
写到存储过程,估计只有写的人能看懂逻辑了.
数据库还是不要做复杂的计算. |
 |
2
msg7086 2018-02-26 16:08:58 +08:00
想办法堆查询缓存？
企业开发更注重可维护性，如果写入存储过程以后会令维护性大打折扣的话，就不建议放。 维护性比几台服务器的钱可是贵多了。 |
 |
3
moshao6 OP |
|
4
msg7086 2018-02-26 16:22:43 +08:00
@moshao6 一般是想办法让查询缓存发挥作用。你可以把每次要查的请求列出来，看看哪些是可以提前合并放在程序里缓存起来的，哪些复杂查询是可以分割成简单查询的。具体情况要具体分析了，这个我也帮不了你。
|
 |
5
whitev2 2018-02-26 16:41:54 +08:00
再看一遍括号里的内容
|
 |
6
l00t 2018-02-26 17:25:36 +08:00
规则和参数可以用缓存方式处理，这样不需要反复读取数据库。你都不需要用什么查询缓存，直接缓存全表就行了，把相关的表全部缓存到服务端的内存里。
写到存储过程里也行，但是写到存储过程里的话，该做的数据库查询还是要做的，减少了一些网络传输延迟罢了。你得先写个试试看效果，到底写到存储过程里能否满足要求。至于存储过程的维护性我觉得你不需要考虑那么多。存储过程那么简单的东西，新人培训一下也能迅速学会的。 |
 |
7
leeg810312 2018-02-26 17:29:19 +08:00 via Android
存储过程不仅是维护性问题，还有调试测试都非常麻烦。如果配置和规则变动较少，可以考虑用缓存，不要每次都读取数据库，在内存中做运算肯定足够快了
|
 |
8
glues 2018-02-26 17:42:56 +08:00
存储过程上个世纪的东西，早该抛弃了
|
 |
9
sujin190 2018-02-26 18:10:58 +08:00
不能，维护太麻烦，程序扩容升级修改很容易，数据库很麻烦，也很容易把数据库搞崩
|
 |
10
Aksura 2018-02-27 22:33:56 +08:00 via Android
用的商业数据库，和操作数据紧密相关的可以放存储过程。用的 mysql 之类的，还是在应用里做吧。
|
Select Language