很多开发者一提到 SQL 就“谈此色变”，觉得难以调试、难以定位 bug
最后就是一句话，就是这个东西碰不得，是邪教。
存储过程这个东西存在这么久，不可能一无是处吧
有没有可能，像 TypeScript 转译为 JavaScript 一样，有一种高级语言可以：
-
编译成各类数据库支持的 SQL （比如 PostgreSQL 、SQL Server 等）；
-
根据目标数据库的特性自动优化生成对应代码；
-
如果使用了目标数据库不支持的语法，比如在目标是 PostgreSQL 时用到了 SQL Server 的专有语法，那么编译器应能直接报错并给出明确提示；
最好还能在开发阶段提供类型检查、智能提示和跨平台兼容性检查。
 |
101
xuanbg 8 小时 22 分钟前
存储过程不是洪水猛兽，但滥用存储过程是。任何技术都有其适用场景，该用就用。不会用可以学，也可以找会的人来做。但因为自己不会某项技术，或者无法驾驭利用好这项技术，就视其为洪水猛兽的话，我只能说“你高兴就好”
|
 |
102
RicardoY 4 小时 33 分钟前
当你需要把逻辑放的离数据足够近，且需要事务支持的的时候，存储过程（或者 trigger ）非常的有效
|
 |
103
shakoon 4 小时 14 分钟前
对于需要进行日终批处理的业务系统来说，存储过程简直方便出天际。把公共逻辑做好解耦，充分运用好函数、包，写好注释，存储过程的维护和其他语言一样，没有什么难的。可惜现在的各种国产数据库对存储过程都支持得很不好（甚至很多不支持的），离开 oracle ，以后确实会很少再用到存储过程了。
|
 |
104
ivvei 3 小时 52 分钟前 via Android
@aureole999 国内哪个证券公司不用存储过程？
|
|
105
ivvei 3 小时 50 分钟前 via Android
@shakoon 不是很多都是 pg 改吗？ pg 的这点能力还是远强于基于 mysql 的那些的。我看国产数据库很多还会考虑和 Oracle 的兼容性。
|
 |
106
aureole999 3 小时 24 分钟前
@ivvei 我不在国内
|
 |
108
chihiro2014 2 小时 39 分钟前
不如代码用 ORM 操作数据库方便，存储过程 debug 比较麻烦，维护很痛苦。我们组有个存储过程，每天跑都不一定跑成功
|
 |
109
ssxwcz 2 小时 15 分钟前
这玩意写起来太费劲了，debug 麻烦，维护起来成本太搞了，而且写起来动则几千行，看的头都要爆炸了。
|
Select Language