吐个槽，真受不了公司恶心的存储过程了
我所在的公司是一个小公司，但是所面向行业的数据量却很大，所以要经常使用存储过程，为了提高查询效率，这可以理解，但是，恶心的是，公司老一辈的把几乎所有的业务逻辑全都写在存储过程里，java代码中根本没有多少业务逻辑，连数据校验，时间判断什么的也全在存储过程里面，后来的人也效仿老一辈，一个存储过程基本上都是四五百行，大家改来改去，注释又少，我嘞个去，你的看半天才知道他写的语义是什么。
在这里，你基本上不需要什么java代码基本工，只要你存储过程用的熟练，业务熟练，你就可以立足了。
我刚到这的时候，天天头疼，就是因为看存储过程看的了。
下周辞职，再也不想看到这恶心的存储过程了！！！！！！！！！！！！！！！

------解决方案--------------------

------解决方案--------------------
调试一行行的走 走三遍怎么也懂了吧！

这样的公司呆半年，岂不是数据库学得非常好？
------解决方案--------------------
计算逻辑下推数据库，是一种非常有效的提升性能的手段，不过估计有点用过度了。
------解决方案--------------------

探讨

调试一行行的走 走三遍怎么也懂了吧！

这样的公司呆半年，岂不是数据库学得非常好？

------解决方案--------------------

探讨

引用:

调试一行行的走 走三遍怎么也懂了吧！

这样的公司呆半年，岂不是数据库学得非常好？

恰恰相反，数据库调试学得倒是很好，系统的业务逻辑和数据库结构设计屁也学不到。

------解决方案--------------------
 
表示理解。
------解决方案--------------------
某些行业的要求吧...业务逻辑必须在存储过程中完成.....
其实你只看到了不好的地方...好的地方被你忽略了...如果所有的工作都在存储过程中完成..那么只需要维护存储过程就好了...JAVA发布什么的还是很麻烦的...小的修改基本改改过程编译一下连重启都不用就可以用了...JAVA还要打包发布重启什么的..麻烦....
而且就算出了问题..就知道问题在存储过程里而不是到处找是java出错还是存储过程出错....这个问题定位其实是个麻烦事....如果在java里和存储过程里都有业务逻辑..那出了BUG什么的定位都要定位死人...
------解决方案--------------------
这个确实有点过了
------解决方案--------------------
楼主 祝你好运~ ~
------解决方案--------------------