存储过程真的很难么？

[v2overflow]

新领导要求不要用存储过程，说因为存储过程太复杂，后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理，比如复制一张表：先 select 到对象中，再把这个对象 insert 到目标表...和他说 CTAS，他说太复杂，和他说效率，他说可以加机器...

如果说过于依赖存储过程会对后续数据库迁移有影响我觉得是有道理的，但他貌似根本没想到这一层，而且既然用数据库了，不能用 SQL 实在不能理解

[ebingtel]

我也觉得你领导是对的……好的程序大把，好的 DBA 凤毛麟角……自己觉得顺手，后面给谁维护呢？

[cloudbeyond]

领导是对的，程序易改，数据库难改，程序好扩展，数据库不好扩展。用廉价资源保护重要资源

[lihongjie0209]

数据库不带任何业务逻辑是正确的做法

[sunny352787]

再加一条，存储过程没法进行版本控制

[Takamine]

领导是对的。
当远古业务用存储过程发生死锁的时候，你可知多刺激。

[annielong]

是不是前后端分离，有专业的 dba 吧，有些需求还是存储过程好用，我手头经常定制新增定制报表，就前台做一个通用类，数据一个报表一个过程，新增修改直接在数据库改，也不用发布新版本

[niubee1]

存储过程是用小机装 Oracle 时代的做法了，实际上等于是把业务逻辑和数据存储耦合在一起了

[aborigine]

存储过程很简单，但是维护很麻烦很难，要是改需求就更恶心了

[webdisk]

@niubee1 一直好奇写字台大小的小型机里面长什么样子

[v2overflow]

@cloudbeyond 问题是 SQL 都不用的话，还用数据库做什么…我们是做批量维护的功能，大部分应用场景就是根据某些条件去更新某字段，以及备份，加载这些，复制表用 java 一条一条的 select 再 insert 这种我真是从来没想到过

[pagxir]

这不是难不难的问题，而是该不该的问题。

[PerFectTime]

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

简直一座屎山...

[v2overflow]

@pagxir 其实我觉得不用存储过程我可以接受，我也说了可移植性不好，但领导那边连标准 SQL 都要求避免使用……

[pagxir]

@v2overflow 这要取决于你们的业务，还是该不该的问题。

[metrxqin]

傻子才用存储过程，知道为什么吗？

可维护性 0
可测试性 0
可重用性 0
可扩展性 0
可移植性 0

[dobelee]

1. 存储过程不难
2. 你领导是对的

[oaix]

就楼主说的这个需求不是可以用 insert into select 语句吗，这也不让用吗？
INSERT INTO table2 SELECT * FROM table1;

[akira]

交次学费就知道为什么不用存过了

导数据那个不用 ctas，应该是有别的原因 问具体呗

[v2overflow]

@pagxir 我认可根据业务功能去做技术选型，之前也一直是这么做

但新来的领导要求所有问题都统一，比如不用存储过程就连 SQL 也都不用，不管应用场景，字段求和就是记录扫出来 java 里面加，update 就是符合条件扫出来，java 改字段再 update 进去，这种真的是好设计么？还是我思想过时了？

另外，移植性，灵活性是理由，我认可
难度，可维护性我不觉得有什么问题

[wd]

进了垃圾公司，后续都是招聘垃圾程序员，自然没有几个能接存储过程的。解决办法就是进个牛逼公司，进不去就听你领导的。