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