存储过程真的好快!

你说的是多版本ＳQL就是指多版本的存储过程吗？

做项目和做产品是不一样的。产品通用性要强得多，可以要你for oracle,for sybase，for    db等。对项目就要求少得多。而且一个项目交接后基本上很少存在要去换数据库的。用存储过程。有时候还就是为了修改业务方便。我们就是因为业务多变把很多业务写到存储过程。这总比隔两天改程序重新部署强。当然缺点也不少。就像所说的非面向对象，调试不方便等。总的来说用或不用，怎么用看场景平衡吧

是的，他们的做法是提供好几套数据库脚本、存储过程、自定义函数等

恩
thomas kyte的那本书有比较详细的阐述，即使是所谓的标准SQL，不同的数据的具体实现细节也有很大的不同。一些你在SQLSERVER执行的很好的SQL跑到ORACLE上会出现你难以想象的问题。
实际操作中，想一套SQL直接跨数据库，基本是不太可能的事。
既然想一套SQL跨数据库不可能，那么把业务放在存储过程中也是可以接受的。。

对于thomas kyte的理论，我没有实际的操作经验，毕竟我的oracle水平实在是菜。让我把业务放到SQL储存过程中还没有哪个胆子。不过很希望能看到这个帖子的回覆里面能有把业务核心都放到存储过程中实施，并且起到优良效果的大大出来介绍下自己的经验。

老兄有相关的经验不？最近我们的项目中遇到很多oracle的问题，因为项目里面没有oracle牛的DBA，一些东西搞得我很痛苦。开始狂补oracle了。开发人员不了解数据库还是不行啊。哎

这个是个人的偏好了，那就看你的驾驭能力了，无论是在哪一边，做的规范合理，满足需求，都是可行的。条条大道通罗马。

首先，你所说的存储过程调试不方便是不存在的。在用对了工具时，存储过程的调试对于数据库应用来说，比其他语言都更为方便。用一下PL/SQL Developer试一下。

第二：A客户要用Oracle,B客户要用sybase的问题。很好解决，我们只提供Oracle版本的产品。就算是和IBM合作，也没有使用DB2。Oracle就是比其他数据库好，没有办法。当然Oracle也是最贵的，但是对于大型项目来说，我们的客户不会在乎数据库的价格。这是他必须要付出的。

第三：关于存储过程维护难的问题，更是可笑。我们的核心计算几乎全部是PL/SQL写出来的。经常会有写得极好的成千上万行的PL/SQL存在。而对于Java来说，我觉得面像对象的东西，很多个Class写在那儿，可真正专注于计算的，也就是几行。大多数Java没有在计算，但Java可以用来搭出很好的架子来。我们公司的做法就是Java搭架子 + PL/SQL的核心计算。极好。关于这个做法，就我所知，在真正需要强大计算的金融保险行业极为流行。这是实践出来的东西。

也许那些只是简单的CRUD的应用，才会觉得PL/SQL没什么用。

你认为有实质性的障碍会导致存储过程不能打断点吗？

这个根本不是存储过程的问题，是开发工具的问题。

PL/SQL Developer试用一下。谢谢。

PL/SQL Developer支持基于TSQL语法的存储过程调试吗

不跟你说了。受不了。