这是一个创建于 1977 天前的主题，其中的信息可能已经有所发展或是发生改变。
新领导要求不要用存储过程，说因为存储过程太复杂，后续的人不好接手... 要求所有数据的处理都读出来用 java 程序处理，比如复制一张表：先 select 到对象中，再把这个对象 insert 到目标表...和他说 CTAS，他说太复杂，和他说效率，他说可以加机器...
如果说过于依赖存储过程会对后续数据库迁移有影响我觉得是有道理的，但他貌似根本没想到这一层，而且既然用数据库了，不能用 SQL 实在不能理解
 |
101
rockyou12 2019-07-01 13:12:11 +08:00
@l00t 首先业务是老业务，然后跑了很多年更不敢动，行数不多但都是 3、4 层的子查询，谁愿意排查谁去查吧，当时领导自己写的存储过程他自己都在骂，我还是老老实实给他重启下服务就是了
|
 |
102
q397064399 2019-07-01 13:13:09 +08:00
@lihongjie0209 #97 别跟老古董争了，我之前一家公司 组长也是喜欢用存储过程.. 还美名其曰学起来 花不了多少时间，我有这个时间 用 Java Python 把迁移程序写好两遍了。
|
 |
103
v2overflow OP 本来只是吐个槽，没想到这么火，看来大家对存储过程怨念很大，我也没说太清楚
我这边做的系统是和联机系统分离的，主要做数据加工和报表，这边接手系统也两年了，原先我也是没用过存储过程的，接手后现学的，我觉得最大的优点就是直接操作数据减少 io 交互，效率高，所以一些不需要落地的加工我倾向用存储过程做，我们这边也没用到什么复杂的业务逻辑，真正复杂的也是用 java 实现的，另外考虑到去 ioe，后续数据库可能会变，我们其实已经在避免使用存储过程和一些与数据库版本有关联的 SQL 特性。 这个新领导之前在日企做 COBOL，来了先是说数据库没有文件读写效率高，让我们把数据都存成文件，他的理由就是同一份数据文件 cp 的时间比用 java select 再逐条 insert 到新表快很多，我说你用 ctas 呢，他又开始说存储过程难上手啥的，且不说 ctas 算不算存储过程的问题，就是觉得那边在纸上谈兵，完全脱离实际 |
 |
104
andy2415 2019-07-01 13:33:08 +08:00
难写
难改 难维护 难测试 难迁移 综上,听领导的 |
 |
105
Aresxue 2019-07-01 13:40:46 +08:00
不难，但是有学习成本，现在的趋势是把业务放到后端语言里去，数据库只做简单的存储功能，没看到那么多公司把外键都拆了嘛。
|
 |
106
weizhen199 2019-07-01 13:56:45 +08:00
听领导的别 bb
还有，存储过程跑的就是快，对程序员的要求自然也高一点，很多人读起来和死了🐴一样那也没啥办法。 就算异构的数据库迁起来和 c#迁 java 相比工作量还是少一点吧。 |
 |
107
zichen 2019-07-01 14:08:13 +08:00
楼主应该没维护过上千行的存储过程吧？前东家就是所有业务都是依赖存储过程，包括定时作业，数据报表，everything 你能想到的都是存储过程，你可以试试出了问题怎么排查。
|
 |
108
yulitian888 2019-07-01 14:12:21 +08:00
"因为存储过程太复杂，后续的人不好接手"
前半句是错的，后半句不完全对。 存储过程（语法）本身不复杂，就是纯粹的 SQL 语法，复杂的是用存储过程编写的查询逻辑。而这种复杂的逻辑，无论是用存储过程还是用程序代码来实现，都不会变简单。 至于后续的人好不好接手，取决于对业务的熟悉程度，对数据表的熟悉程度，而不是取决于实现方式。只要文档缺失，你换成 java 写一样复杂的逻辑，难道就好接手了吗？ “要求所有数据的处理都读出来用 java 程序处理” 嗯，那么应该让这个领导试试看做千万级的数据表同步功能试试看吧？不复杂，A 表到 B 表，结构一致，不跨库，做程序维护一下数据同步就好！ 实际上如果存储过程真的这么罪大恶极，那么它显然不会成为行业标准（ SQL 99 ）的内容，早就应该被历史的车轮碾成渣渣了。放弃存储过程意味着什么呢，各种数据库技巧，比如临时表、表变量、已缓存的查询计划等众多数据库特性基本等于不存在了。这种把数据库打成残废的招数，呵呵呵~~~~ 另外，前面有人说不能源码管理，纯属胡扯。所有能写成脚本的东西都可以被源码管理起来。 |
 |
109
QQ2171775959 2019-07-01 14:13:13 +08:00
存储是有一定的难度的，还需要考虑很多因素的，设备也很重要的。
|
 |
110
lolizeppelin 2019-07-01 14:24:47 +08:00
是不是可以总结为 没有月薪 2W 以上专职 dba 就不要用复杂的存储过程
|
|
111
rockyou12 2019-07-01 14:25:14 +08:00
@yulitian888 sql 是标准，但不同的数据库 sql 都有区别这你要同意吧？再说 sql 工具有其它语言的多，你写 java 用 idea 再蠢的程序员也蠢不到哪去好吧，sql 有同等量级和功能的工具？
|
|
112
yulitian888 2019-07-01 14:54:07 +08:00
@rockyou12 so?不同数据库的区别是客观存在的能说明什么？抛弃个性化功能，只使用共性功能是唯一正确的选择吗？呵呵呵~~~
真实项目中，数据库更换的概率实际发生的情况极少，而且几乎都是本地库上云，或者 SQL 换成 NoSQL 的迁移方案居多。类似 MySQL 换 Oracle 啊，SqlServer 换 MySQL 啊，这种事情只存在于培训班的老师嘴里 |
 |
113
weicy 2019-07-01 14:56:15 +08:00
存储是有一定的难度的，还需要考虑很多因素的，设备也很重要的。
|
|
114
rockyou12 2019-07-01 14:59:37 +08:00
@yulitian888 并不是数据库迁移，而是学习有成本，比如像 mysql timestamp 以前只能到秒，而且会自动更新。这样的细节新手菜鸟就不会注意
|
 |
115
sambawy 2019-07-01 15:01:14 +08:00
设计方案最终应还是取决于业务场景
如果是传统行业类似银行这种，需要不中断业务的情况下更新代码业务逻辑，基本上都还是用存储过程来干的 但是站在我个人的角度，也是很唾弃维护存储过程的，虽然自己写的时候还是很爽的 |
 |
116
akira 2019-07-01 15:11:11 +08:00  1
lz 都说了能理解不用存过， 他不理解的是为什么不能用 sql，这个反正我感觉是蛮扯的，肯定是哪里理解有偏差了
|
 |
117
LeeChP 2019-07-01 15:20:59 +08:00 via iPhone
@youEclipse 当年做拓展功能，看到这个 plsql，我的第一反应是辞职！
|
 |
118
v2orz 2019-07-01 15:31:06 +08:00
之前听过一个理论，数据库用来做存储而不是计算，现代系统里面绝大部分情况都是数据库最容易出现瓶颈，所以尽量将计算工作放到应用中
|
 |
119
hhhzccc 2019-07-01 15:49:59 +08:00
@lihongjie0209 存过过程怎么不能记录日志呢？自己不知道，不代表没有。
|
 |
120
taaaang 2019-07-01 15:58:32 +08:00
这让我想起了曾经就职的一家搞金融（ P2P ）的公司，很多批处理都是存储过程实现的。维护起来真的是难受得要死, 至少在当时想要去排查一个问题，或者理清楚一段逻辑，比让我学一门新语言还痛苦。最崩溃的是，没有好用 IDE，基本上就是记事本的方式在查看。 而后就是重构，简直是炼狱。
|
 |
121
lannoooW 2019-07-01 15:58:40 +08:00
第一个月：公司决定要把 MySQL 数据库全部换成 Oracle 啦！所有的存储过程在 Oracle 中全重写一遍吼；
第二个月：公司决定把 Oracle 换成 PG 啦！所有的存储过程在 PG 中全重写一遍； etc：、、、 而用程序迁移数据的话基本上支持换个驱动的区别┑(￣Д ￣)┍ |
 |
122
aloyuu 2019-07-01 16:11:33 +08:00
屎一样的存储过程
|
 |
123
lihongjie0209 2019-07-01 16:42:59 +08:00
@hhhzccc 我没说没有, 我只是说能做到哪一步, 线程 dump, 断点调试, 日志这些最简单的功能能用的有多少
|
 |
124
wenzhoou 2019-07-01 16:55:15 +08:00 via Android
@yulitian888 概率小看相对什么而言。你碰到了就是 00%。另外传统企业里面的系统，系统升级伴随着数据库切换也是很常见的。
|
 |
125
saulshao 2019-07-01 16:57:09 +08:00
存储过程主要的问题不是难写，而是难以理解和维护。
如果假设一个软件是由一个头脑清醒的人一直编写和维护，在整个软件的生命周期内理论上存储过程其实更简单。 如果所有的软件都是基于定制开发的，存储过程其实不算是个坏的方案。但是现在大家不是都要搞产品化吗？ 正如前面网友的距离，换个数据库，所有的存储过程基本都要重写一遍。并且更严重的问题是重写之后你要搞单元测试还很费劲。 |
Select Language