存储过程真的很难么？

问错地方了，这里大家吃屎吃多了，大部分都应该是把数据库当做一个可靠的 K/V 库用的，数据库本身的特性能不用最好不用。

你可能不知道一个项目里有几万行存储过程是什么体验，我们一般用两个字形容这种架构师，傻逼！
维护一下，你就懂了！

领导没毛病，所有的存储过程一经使用都是遗留代码，过半个月你自己都不认得是谁写的。

@v2overflow 翻了下记录，你说对了 SQL 真不是必选项。

你见过 2000 行的存储过程吗？又想起来被存储过程支配的恐惧了。

什么年代了，居然还有人想着用存储过程？？回帖里基本都是否定这种的。如果你不信，你可以写个几百行存储过程，隔一两个星期再去阅读试下。

我也这么觉得，一般的小公司普遍用人紧张，牛人留不住，做项目不敢做的太高深怕被员工牵制

确实是很快恐怖。

领导考虑的比较全量，是个好领导。

新人就多学习，别天天想着领导是 sb

只有在证券公司呆的时候见过存储过程，互联网公司没见用过的…

存储过程依赖具体数据库，甚至依赖具体版本的数据库，你说呢。

@oaix 就算你说的这个场景。你能保证业务不变更吗。
回头领导一句话，你个我把这个字段和这个字段合并一起。然后你就傻眼了。还是得要换成应用侧处理。
所以我觉得，别费那么大劲。就给搞成 Java 的。能跑就这么跑，不坑后人。

1000 行的存储过程 玄学调试

新领导要求不要用存储过程，说因为存储过程太复杂，后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理--------这样的人和公司和论调大把，甚至阿里也是这样说。但我说这纯属放 p。这是程序员 dis，dba 的一种说法。是程序员 dis 数据库开发人员的一种说法。

和“ php 是世界上最好语言”一样，是一种偏见！！！

存储过程没法进行版本控制-----凡是语言都能进行版本控制。

数据库不带任何业务逻辑是正确的做法。------这是不可能的！
业务需求数据库带有逻辑。你这种论调，只是把逻辑用另一种语言来实现而已。
正确的是，数据库必须带有逻辑，
必须带有冗余。
必须分冷热数据。
必须带有子库。即子库+母库。而字母库 1，又和字母库 2 互联。形成分布式库。
字母库之间必须用语言，来互通消息。
字母库之间必须用语言，来搬运数据。

至于用这种语言，还是那种语言。用不用 sql，要扬长避短，而不是一味 diss sql。
有的时候，你不用 sql 事务，你难以解决死锁。
你不用唯一索引，难解决重复问题，要用程序，你就要引入分布式全局锁。
这些难题用数据库，一下子就解决了，或一下子就没有了。



一味 diss，我想大概有这么几个原因：
1 没有 dba。但应用开发人员很多，所以强势。
2 感觉，存储过程，sql 难，反人类。不好调试，没执行记录。------这些是 [应用开发人员] 偏见， [库开发人员] 不这么看。
3 感觉 dba 难以沟通。难以协调 [应用开发人员] 和 [库开发人员] 之间的工作。

结论：
是偏见，但是偏见者众。
数据库应该分层，第 1 层应该是内存的，因为快，应该是亲 [应用开发人员] ，如 redis。
第 2 层，第 3 层。每层（字母库）之间有冗余，有逻辑整理，逐渐分冷热。逐渐符合数据库范式。

领导是对的,不是每个人都会存储过程。未来也不好交接，没有专业 DBA 团队的公司不要用，互联网公司也不要用。很坑

我工作这么多年，还没见过有用存储过程的公司。

偷偷的告诉你:存储过程很简单，也没有第三方库，就一个好处:快！比任何方式操作数据库都快！没有可比性，尤其涉及到多表数据分析，用外部语言简直慢的不行，大量的网络 io 交换，大量的计划，总之存储过程就一个字:快！
but，一堆维护问题，线上数据库基本不支持，移植基本死翘翘

运营过程中就遇到过这坑。排查程序压根没发现问题。最后才发现是存储过程的问题。折腾死了。

你领导没错，存储过程的维护成本和程序的维护成本完全不是一个级别的。除非不得不用存储过程，否则别用存储过程

看到存储过程里，上千行的包含业务逻辑的 sql，你就知道为什么不推荐使用存储过程里