SQL存储过程真过时了?

我想请教下各位大虾，
    现在程序中使用SQL存储过程真过时了吗?难道用在程序中使用了SQL存储过程就真的打乱了项目的三层架构思想吗？
    最近我在一个公司听到公司里面的软件设计总监和某经理在某位员工说到程序中使用存储过程的时候尽然说使用SQL存储过程已经过时了，那是老的旧的设计思想，而且使用了SQL存储过程的话打破了软件的多层架构的思想，他们把所有的本来可以使用DB服务器上的资源的计算全都搬到自己程序中的业务层来运算，本来使用存储过程可以让报表跑的更快的，他们不用存储过程，而在他们的业务层去算，到最后软件的报表生成速度让每个客户都埋怨说太久了。
    大家说说现在存储过程真的是过时的东西吗？打乱了程序的多层架构思想吗?
    我到现在都想不通为什么他们有这样的想法。明明用存储过程可以让报表效率更高为什么不用呢？难道是这位所谓的软件设计总监和某经理从来没用过存储过程，而且也不会写存储过程？

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

我支持业务逻辑不放在存储过程的说法，存储过程的对业务的抽象能力真的不够（Oracle可能强点），除非你的业务都是简单的CRUD。但不支持一概不用存储过程的说法，象报表这种大数据量获取，又没什么逻辑性的，应该考虑存储过程。
仁者见仁智者见智，老总们以为现在的电脑快的都是8核4.0G的cpu 16G的内存。
如果程序要支持多种数据库的话，当然不能直接写存储过程了。不可能为SQL、Oracle、DB2各写一套吧？你们总监的思路是对的。速度慢的问题只能说中间层里面的代码写的不完善，可以用另外的思路去解决。
不过事情要因时而异，如果你们的软件注定只能在SQL上运行，那就完全没有必要墨守成规了，该用存储过程就用吧。
这个要看具体应用而点吧，一棒子打死难免有失偏颇的1、从性能角度看，存储过程无疑是好的选择2、从可维护性角度看，存储过程对具体DBMS依赖度高，移植工作量大3、从系统结构（在很大程度上会影响到系统的可读性、可维护性、质量、性能）角度看，存储过程好像与流行的三层、多层结构格格不入。都压扁到数据库中了，没有层了。
但个人认为这也只是从系统的大结构（或称为架构）来看的。是啊，除了表现层，逻辑层、存储层都由DBMS实现了，确实没有分层概念了。
那是不是这样的设计就很失败呢，不尽然。
(1)、我们回头想一想，为什么要分层？分层的目的是多方面的，其中应当包括一条提高系统可读性。存储过程的可读性比一般开发语言差吗？影响代码可读性的主要因素是语言吗？
(2)、所谓分层概念，是不是也要区分逻辑分层和物理分层，前者在设计考虑，再细分当然还有架构设计、模块/子系统设计、详细/代码设计等；后者则是系统的物理实现，部署方式上的分层。如果设计得当，存储过程代码是不是也能够做到松散耦合、结构优良、条理清晰、层次分明呢？至于部署实现上的分层，实际上可能考虑性能和安全性多一些，结构倒是其次了4、当然，实际应用中完全用存储过程来实现整个系统很少（但不是不可能，特别是现在大型DBMS在报表展现上已经做到相当程度了）。原因主要考虑的是移植性方面，毕竟不会有人乐于每天做代码移植性工作。但正如楼主好多人说的，在做大计算量的报表时，很多系统都会使用存储过程。原因当然主要是考虑性能因素，试想，如果一个报表需要几分钟才能出来，没有用户能够接受的。
嘿，等你们总监发现有SOA这种东西，就会说存储过程真他妈的好。
to #29SOA和存储过程没任何关系
少用存储过程是从维护成本的角度考虑的,如果在程序业务逻辑中实现,将来的可移植性,可维护性比存储过程强很多.大型项目为了项目的可维护性和极大的降低维护成本,放弃使用存储过程,是一种明智的选择我认为,
试想你的客户今天说MSSQL比较好,你给他写了存储过程,实现了业务,过半年,他说听说Oreacle比较好,要换Oreacle你怎么移植,从头来做吗??想必是难以完成的任务!!!
我们之前的项目都是把CRUD这种操作放到存储过程的，业务逻辑都不会跟数据库直接打交道的
很多原因会导致更换数据库，Sqlserver、orcale价格巨贵。如今又在开始查盗版，很多用户会转向使用没有版权问题、最好是免费的数据库方案。对于普通用户可以使用免费数据库，对于有钱用户使用Sqlserver、orcale。做架构的再牛B，也要跟随市场竞争形势来修改设计，呵呵
我用存储过程都是数据库内部使用,外部程序非到必要的时候不会主动调用存储过程的.
存储过程这个东西对于数据库软件本身依赖性太大,不同的数据库内部语言不一样,调用方法不一样,一旦改了数据库,还真是噩梦.所以我只是在数据库内部用存储过程,外部的程序基本上和数据库打交道的都是标准的sql语言.