逻辑是否应该写在存储过程中

[moshao6]

产品的一个推荐时间功能：由几条数据根据当前系统配置的参数和 20 多张规则表计算出最优时间

现象：1、由于系统的全局参数配置上 100 个 2、规则表有 20 多张（数据量不大，多的才 100 条） 该功能根据配置的不同，有不同的逻辑处理，且会读取不同的规则表进行一些逻辑运算、查询数据库次数非常多。正常 1 秒中内完成。 如果规则与参数使用的少，完全满足要求。但是如果规则与参数多了，导致有的时候 5 6 秒或者更久才计算出来结果。

考虑：现在感觉不好优化（主要是查询数据库次数非常多、循环也多）。想把该功能放到数据库的存储过程中，会不会得到一个提升。

PS:该功能后续改动量不大（除非要加新规则和参数）

[xinyewdz]

写到存储过程,估计只有写的人能看懂逻辑了.
数据库还是不要做复杂的计算.

[msg7086]

想办法堆查询缓存？
企业开发更注重可维护性，如果写入存储过程以后会令维护性大打折扣的话，就不建议放。
维护性比几台服务器的钱可是贵多了。

[moshao6]

@xinyewdz 一般写存储过程都会注释的很清楚的 （ PS:不会写 100 行代码一行注释都没有）
@msg7086 维护性是不好，就是想着怎么样优化优化，功能是没有问题

[msg7086]

@moshao6 一般是想办法让查询缓存发挥作用。你可以把每次要查的请求列出来，看看哪些是可以提前合并放在程序里缓存起来的，哪些复杂查询是可以分割成简单查询的。具体情况要具体分析了，这个我也帮不了你。

[whitev2]

再看一遍括号里的内容

[l00t]

规则和参数可以用缓存方式处理，这样不需要反复读取数据库。你都不需要用什么查询缓存，直接缓存全表就行了，把相关的表全部缓存到服务端的内存里。

写到存储过程里也行，但是写到存储过程里的话，该做的数据库查询还是要做的，减少了一些网络传输延迟罢了。你得先写个试试看效果，到底写到存储过程里能否满足要求。至于存储过程的维护性我觉得你不需要考虑那么多。存储过程那么简单的东西，新人培训一下也能迅速学会的。

[leeg810312]

存储过程不仅是维护性问题，还有调试测试都非常麻烦。如果配置和规则变动较少，可以考虑用缓存，不要每次都读取数据库，在内存中做运算肯定足够快了

[glues]

存储过程上个世纪的东西，早该抛弃了

[sujin190]

不能，维护太麻烦，程序扩容升级修改很容易，数据库很麻烦，也很容易把数据库搞崩

[Aksura]

用的商业数据库，和操作数据紧密相关的可以放存储过程。用的 mysql 之类的，还是在应用里做吧。