存储过程真的很难么？

数据库这种底层的东西最好不要和业务有什么牵扯。

我自己是 DBA 出身，我是支持在项目中用存储过程的。
但是要区分场合，事务性的肯定要写在代码里，报表和数据转换之类的操作用存储过程更简单直接

如何你们有专职的 DBA，让他去说服领导，如果没有，你不要凑热闹

@lincanbin 我这边是 ERP 软件甲方，乙方不给开放二次开发，乙方自己开发又慢，测试又不尽力，开发又不尽力。有时候真的超级烦，有的逻辑超想帮他们全部写好细节让他们直接搞直接修……

然后有一天发现他们使用存储过程，于是就进去看……虽然不是 SQL 达人而且只会入门语句，竟然也看懂了不少。顿时对存储过程好感提升……

换了一批人维护，后者肯定会诅咒前面写存储过程的人的。

@ps1aniuge 也有可能不是偏见，是教训呢？
我们线上的机器，应用服务器十几台，如果 CPU 或内存不够了，再上七八台很容易。应用服务器崩了就崩了没事的。
数据库服务器，就两台，如果 CPU 或内存不够了，整个业务死翘翘。
为什么不多搞几台，因为代价和应用服务器不是一个数量级的。我们用的 Oracle 的版权死贵，出了问题请 Oracle 专家来，那个价格真心不便宜，而且耗时间等不起。
曾经出现过，调查 bug 的人去服务器上敲了一条 select 语句，导致生产数据库长时间没反应。后果可想而知。从那以后所有人就知道把数据库服务器当宝贝了。
数据库服务器，就是要 io 性能超好，你看似一次检索出来的数据量太大，但是就算是几百 M 数据这对于内网的数据库，都不是问题。反而是 CPU，有两个问题。一个是版权是按照 CPU 内核数收费的，再一个 CPU 再好也经不起折腾，你把排序，数值加减放到数据库服务器上运算，那就是拿着尚方宝剑去切肉。所以一般数据库专用服务器都放弃 CPU 了。
所以说不是不想用存储过程，实在是条件不允许。
当然你单机跑，或者没上线之前做数据移行，那随你高兴。

所以再强调一遍，不要在数据库服务器上玩火是绝对政治正确的。

写存储过程完全是给后面人挖坑

开发难度：★
维护难度：★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

@ps1aniuge
数据库不带任何业务逻辑是正确的做法。------这是不可能的！

请你证明一下数据库必须带业务逻辑

@PerFectTime 然鹅我司就是遇到了 5#所说的远古业务死锁的问题....

简直一座屎山...

屎山这个词笑死我了

当年还是菜鸟程序员的时候遇到有外键删不掉数据这种事以后，我就发誓再也不在数据库上搞任何带有业务逻辑的东西了嘿嘿

@LeeChP 给架构师倒一杯卡布奇诺

@v2overflow 醒醒，DBMS 不是 RDBMS，没空没历史遗产倒腾啥 SQL。

挺正常的，我们这主库的数据，要定时放到测试库中和定时清理到 hive 中(大的表数据上亿了)，本来建议使用 kettle，但是领导坚持写 python 脚本,不过好处就是脚本大家都看得懂，有人请假问题也不大。

> 存储过程没法进行版本控制-----凡是语言都能进行版本控制。
肤浅。控制到什么程度？“凡是语言”？给你一坨 Piet 代码你能 diff 得让人看？

> 你这种论调，只是把逻辑用另一种语言来实现而已。
废话。只是工程上能用的“另一种”语言想要比带所谓存储过程的语言实现此类需求能力更稀烂还是不太容易的。

> 必须带有子库。即子库+母库。而字母库 1，又和字母库 2 互联。形成分布式库。
前面的瞎眼论调先无视。整个生命周期都没要分布式的业务，照你这坨还应该没事瞎搞个分布式架构？这是什么精神？

> 2 感觉，存储过程，sql 难，反人类。不好调试，没执行记录。------这些是 [应用开发人员] 偏见， [库开发人员] 不这么看。
抛开实现是不难。但是[语言开发人员]就是要 diss 一坨不知本分还要跨领域碰瓷的 DSL 了，不服？

我还真没见过存储过程，你是刚从书上学来的？

你遇到了一个好领导，珍惜啊。

补充一下，SQL 本质还是查询语言，用来做逻辑性的事情总感觉不合适。

@springz #35 赞同。问题是大学 数据库系统原理 教材里头这玩意反而是难点

唉，上古的屎