工作十年存疑——存储过程OR多层结构 楼主的前提是，这是企业项目，而且是大企业，人家用得起IBM，oracle。如果是个产品，或者是给穷人用的项目呢？数据库ORM都用开源产品的呢？又或者是用于以“不怕折腾，怕不折腾”闻名的互联网行业呢？人家很可能几种开源数据库三天两头换着用。 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 如果楼主做过ERP或者PLM的实施，甚至开发，应该不会有这样的疑惑才对。 确实，比如我原来的公司，是用java开发的系统，里面大部分的功能都是封装在java内的，程序把一部分经常访问的数据，缓存在应用服务器tomcat中，基本上所有的数据操作，都是通过ssh来实现的，比如定时任务，就是分装在java中的，而很少用数据库的作业来定时执行，其实大部分操作，无非就是从一堆表中经过计算，然后去修改其他表中的数据。通过java来实现，有好处，比如系统的可移植性，比如，不管是sql server，还是oracle，程序都差不多，后台换成了其他数据库，基本上程序改动很小。我发现很多程序员，包括一部分资深的程序员，他们对数据库只是达到了了解的程度，只是认为数据库吗，就是sql语句，sql语句嘛，无非就是增删改查，好像也没什么大的名堂，这是在每日早会的时候，我们的部门经理说的。由于我不是java程序员，工作也主要是写sql语句，所以我在看问题的时候，更多从数据库的角度来看待问题，我觉得很多的功能，用数据库可能更合适一点，比如，上面说的定时任务，如果只是表中的数据计算，完全可以写个存储过程来实现，放到作业中，定时调用就可以了。往往是系统性能出现了问题，才考虑会把一些计算，放到数据库端来实现。还有就是规范化，比如写的存储过程完全没有注释，这让人根本没办法修改，而且很多存储过程都有严重的性能问题，开发的数据量很小，等系统运行一段时间后，数据量达到上亿的时候，就会突然暴露出来一堆的问题。当有些重要的存储过程在运行时报错，我后来一看，这个存储过程就写的有问题，这些都严重缺乏测试。所以我觉得，必须要加强培训，加强规范化，加强测试等等，这样才能提高系统的质量 这个世界声音吼得最大的是“职位”最高的人，是否正确并不重要，这是政治对一个相对独立的逻辑，封装到SP里是正道，有哪个语言对绝大多数数据（SETS）处理的效率会好过DB？更多的系统（可以直接点名：KD、UF、SAP等）一上台面就要求高档服务器，但其实系统优化处理得好，对几百G数据量、几百个用户的访问，现今三五万的SVR性能也足够，这仅是技术层面思维在政治层面，一上来就要三五十万的SVR，说起来都十分牛B，而且还有站在这个链条上吃“肉”的人更会推波助澜，在有话语权的人口里，何乐而不为？作为一个IT实权人，只要有或能申请预算，肯定乐意选择三五十万而不是三五万的预算支出，这个大伙儿肯定心知肚明这个世界还也有不玩平板、不玩手机的人，也还有拒绝电力进村的镇区。。也没什么，各有所选择而已 楼主一定是接触IT项目实施、管理的多，对技术特别是DB技术了解得不多的 简单的增，删，改，查直接用SQL， 复杂的查询用存储过程非常复杂的逻辑流程用存储过程（复杂但不易直接用SQL处理的就算了） 我也和楼主一样在思考这个问题.我们的业务逻辑也是封装在存储过程中的.这种模式很好用,性能好是不用说的,核心,复杂的业务逻辑都在存储过程中控制,这对视图层和控制层是是透明的.当然控制层会也根据配置动态地做一些通用的数据逻辑控制.当有业务变化时只需改存储过程就可以,而且是热修改,立即生效的.当然,这样做也是有缺点的.1.版本控制比较麻烦,目前没有比较好用的数据库版本管理工具,当然也不是说没有,我们现在有借助svn及开发的工具在进行版本控制.2.迁移数据库.这是不行的,存储过程只能一直使用同一种数据库.不过,也可以把一些业务放在其他类型的数据库,再由存储过程调用,或直接由应用程序调用(比如说做成服务供调用).3.数据库服务器成本高.业务逻辑全写在存储过程中无疑会需要更好的数据库服务器,而数据库服务器一般比web服务器要求更高,更昂贵.虽然这样可以省掉几台应用服务器,但成本还是较高的.4.代码编辑和调试.在sql方面,编辑和调试工具明显跟不上时代.尤其是调试,基本只能靠print输出信息来调试仅管有这么多缺点,我们还是在坚持这种模式,并且逐渐混合其他数据库或服务,不会所有业务全在数据库中现实,像队列,事务,消息,工作流,数据转移和同步等会改用其他的方式做. 再补充点好处1.性能好是不用说了2.低成本.sql远比其他开发语言简单,只需要招个应界生,或招个水平一般的,简单培训一下就能投入开发.这个人力的低成本可以很大程度上抵消数据库服务器的高成本消耗.你是愿意招一群高水平开发人养着,还是愿意买台高性能的服务器养着呢?而且,在分布式和虚拟化流行的年代,服务器成本将越来越低3.开发低成本的另一个好处是,开发人员可以更多地关注业务本身,不需要管什么设计模式,面向对象之类.开发快速,能快速应对业务需求4.职责更加独立,分工更加明确,应用服务器只需负责接收用户请求并快速做出响应(可以异步),再由数据库负责数据计算(增,删,改).这样开发快速,低成本,高性能的方案有啥理由不坚持呢? 1.存储过程也能配得上 开发简便快捷，真好笑。执行效率高，没有缓存结构的实时硬盘查询能高到哪里去？存储过程究竟带来了那些好处？我看好处就是：我只会存储过程啊！逻辑层拥有各种方便易用抽象手段，存储过程能行吗？迎刃而解 从何说起？2.存储过程有着更高的开发和执行效率？和第一点重复，真好笑。分层能够降低服务器负担？你听谁说的？3.需要付出许多学习成本，但是可以节省更多的开发时间，所谓磨刀不误砍柴工。导致开发失败，项目夭折，竟然能把责任退给面向对象，也只有楼主这样的SQLer才做得出。使用存储过程编写的系统则相对要简单得多？我从来没有看到过易读、易维护的存储过程，难道楼主是在说存储过程只能编写简单的系统？存储过程能够很好地与敏捷开发方法相契合？真弄不明白，存储过程与敏捷开发有什么强关联。4.把数据库视作一个对象，那么接口是什么呢？SQL？如果把CPU视作一个对象，接口是指令流，是不是就不需要SQL了？5.所谓术业有专攻，关系数据库只是一个专注于基于索引的数据持久化存取工具，逻辑处理不是它的重点，所以才会使用SQL这么简单的结构化语言。现在官方的、开源的好用的ORM一大堆，需要购买的是服务吧。6.多层体系需要掌握某种一个框架，对于他们而言只会降低开发成本。对于SQLer而言，短期内加大开发成本是肯定的，因为需要学习新的技能。当然一般来说，用自己熟悉的技术做项目是应该的，但是把自己关在里面就... 存储过程个人觉得还是如果多个系统都要用同一套逻辑的话，存储过程还是十分有用的，可以为不同的系统提供统一的业务逻辑（当然你如果有SOA什么的那就忽略这个）其他时候看具体情况吧，如果数据库服务器本身压力就比较大，那还是少用存储过程反正个人一般能不用存储过程就不用存储过程，那是DBA的领域额改个存储过程都要审批，尼玛，还是程序里好，随便怎么写 其实这也是为什么：java的系统，对硬件的要求，动辄高几倍几十倍，最后用户还是感觉响应速度慢数据库的访问机制，是最高效的了，加上索引合理，使得它的效率可以成千上万倍地提高而应用程序（典型的就是java后台应用）自行实现这些功能，实在是。当然，放在应用程序实现，有一个很大的好处：应用服务器可以任意叠加，而数据库服务器只能提高单机（包括集群、一写多读）性能而单机的性能，到了一定程度，再想提高是很困难的了而机器的叠加，总的性能提高几乎是线性的这个时候，利用应用程序的好处才体现出来了不过，绝大多数系统达不到这个时候所以，只会觉得java系统是个“败家子”。 现在的问题就是 最早期的业务逻辑什么的都是在底层直接做的 后来发现这样的代码不利于维护 因为做产品需要考虑客户的环境 有的客户是不许你安装数据库的 所以要考虑跨数据库 那么用存储过程写就有问题了 如果增加功能或者修改功能 意味着所有的版本（for oracle的，for mysql的等）都要变动 后期的成本很好 于是就想办法解决这种依赖 才有了现在的三层结构 MVC什么的 但是如今大部分的软件都是用同样的结构 并且数据什么的越来越庞大 就开始更多考虑效率问题 怎么优化 于是又回到一开始了 肯定是越底层越快 我也时常纠结一些模式 因为模式本身就是把简单的问题复杂化 毕竟没有模式的时候 还是有那么多优秀的软件诞生 有时写写突然想 这样值得吗 如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用 我说的客户不允许安装数据库是因为客户本身有数据库 不是和数据库关系不大涉及到版权问题 我都花钱买oracle了 为什么还让我花钱买sql server呢我以前的客户就是 另外还涉及到人家的数据库服务器里面有各种保密的东西 你只能把create table那些语句发给他们的技术人员 你只能用ftp把你的应用考到web服务器下你误会我的意思了如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用 如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用这要求产品、项目方同时提供for oracle/for mysql的数据库访问封装至于不直接在数据库操作，那是很正常的，不是 不用存储过程的 原因 如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用我赞同这个观点，还有就是相同的数据库的不同版本对存储过程的支持也是不同的。再加上搞信息系统开发的一般都是不大的软件公司，如果使用存储过程，那么公司还要养一个专门的负责存储过程的人员，他与其他编程人员是完全不同的，这也增加了项目的风险。 如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用我赞同这个观点，还有就是相同的数据库的不同版本对存储过程的支持也是不同的。再加上搞信息系统开发的一般都是不大的软件公司，如果使用存储过程，那么公司还要养一个专门的负责存储过程的人员，他与其他编程人员是完全不同的，这也增加了项目的风险。如果应用系统的开发者都没人熟悉数据库，那他们开发的系统的运行效率能不慢吗？数据库方面的优化与否，效率是成千上万倍的差别，用户在硬件上的投入能增加成千上万倍吗？ 如果用户不允许安装数据库，说明这个系统与数据库关系不大。否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用这要求产品、项目方同时提供for oracle/for mysql的数据库访问封装至于不直接在数据库操作，那是很正常的，不是 不用存储过程的 原因我说的意思是把if() {} else {}等写在程序里 不是写SQL的case then 这就是楼主说的问题 有没有必要的问题 不是对错的问题你说的对 我理解 但是你没理解我和楼主说的意思我的想法是 复杂的逻辑直接写在数据库 没必要写在程序上可能是我表达不好 居然还要再解释一次 你所谓的千上万倍的差别，顶多就是基于B+树的索引优化，与存储过程实在是扯不上关系，而且数据库也就仅仅是能做好这一件事。数据库再怎么优化都是基于硬盘读取的，虽然数据库也有缓存系统，但是不可能具有业务针对性，仅仅就是一个FIFO的查询结果集合，不仅效率低下，而且内存浪费严重。而应用程序缓存是基于内存的，命中率一般的情况相对于硬盘读取也是成千上万倍的差别，就算是分布式内存缓存也差不多。举个例子，比如1000W普通数据的分页查询，数据库查询一般都是0.1s-0.3s左右，而内存查询是0.00XXXms左右。 【基础】建索引疑问？ 怎样根据两列的值来合并行 如何用sql语句察看一个表的触发器内容 [求助] 在视图中如何根据列值创建新列！！ 求一ＳＱＬ语句 关于删除同样记录的 SQL server vk 如何能暫時不要將操作改入log中，如oracle的alter table tablename no loggging,請指點！謝謝 从第一个表中取出某一字段的值作为第二个select。。from。所要用到的表（要求遍历第一个表中该字段的所有值） B2C电子商务定单模块数据库设计问题 有关SQL Server中的用户默认数据库 游标的定义问题 sql拼接数据行 sql中怎么判断某个字段的值是否连续？
对一个相对独立的逻辑，封装到SP里是正道，有哪个语言对绝大多数数据（SETS）处理的效率会好过DB？更多的系统（可以直接点名：KD、UF、SAP等）一上台面就要求高档服务器，但其实系统优化处理得好，对几百G数据量、几百个用户的访问，现今三五万的SVR性能也足够，这仅是技术层面思维在政治层面，一上来就要三五十万的SVR，说起来都十分牛B，而且还有站在这个链条上吃“肉”的人更会推波助澜，在有话语权的人口里，何乐而不为？
作为一个IT实权人，只要有或能申请预算，肯定乐意选择三五十万而不是三五万的预算支出，这个大伙儿肯定心知肚明这个世界还也有不玩平板、不玩手机的人，也还有拒绝电力进村的镇区。。也没什么，各有所选择而已
复杂的查询用存储过程
非常复杂的逻辑流程用存储过程（复杂但不易直接用SQL处理的就算了）
我们的业务逻辑也是封装在存储过程中的.这种模式很好用,性能好是不用说的,核心,复杂的业务逻辑都在存储过程中控制,这对视图层和控制层是是透明的.当然控制层会也根据配置动态地做一些通用的数据逻辑控制.当有业务变化时只需改存储过程就可以,而且是热修改,立即生效的.当然,这样做也是有缺点的.
1.版本控制比较麻烦,目前没有比较好用的数据库版本管理工具,当然也不是说没有,我们现在有借助svn及开发的工具在进行版本控制.
2.迁移数据库.这是不行的,存储过程只能一直使用同一种数据库.不过,也可以把一些业务放在其他类型的数据库,再由存储过程调用,或直接由应用程序调用(比如说做成服务供调用).
3.数据库服务器成本高.业务逻辑全写在存储过程中无疑会需要更好的数据库服务器,而数据库服务器一般比web服务器要求更高,更昂贵.虽然这样可以省掉几台应用服务器,但成本还是较高的.
4.代码编辑和调试.在sql方面,编辑和调试工具明显跟不上时代.尤其是调试,基本只能靠print输出信息来调试仅管有这么多缺点,我们还是在坚持这种模式,并且逐渐混合其他数据库或服务,不会所有业务全在数据库中现实,像队列,事务,消息,工作流,数据转移和同步等会改用其他的方式做.
1.性能好是不用说了
2.低成本.sql远比其他开发语言简单,只需要招个应界生,或招个水平一般的,简单培训一下就能投入开发.这个人力的低成本可以很大程度上抵消数据库服务器的高成本消耗.你是愿意招一群高水平开发人养着,还是愿意买台高性能的服务器养着呢?而且,在分布式和虚拟化流行的年代,服务器成本将越来越低
3.开发低成本的另一个好处是,开发人员可以更多地关注业务本身,不需要管什么设计模式,面向对象之类.开发快速,能快速应对业务需求
4.职责更加独立,分工更加明确,应用服务器只需负责接收用户请求并快速做出响应(可以异步),再由数据库负责数据计算(增,删,改).这样开发快速,低成本,高性能的方案有啥理由不坚持呢?
2.存储过程有着更高的开发和执行效率？和第一点重复，真好笑。分层能够降低服务器负担？你听谁说的？
3.需要付出许多学习成本，但是可以节省更多的开发时间，所谓磨刀不误砍柴工。导致开发失败，项目夭折，竟然能把责任退给面向对象，也只有楼主这样的SQLer才做得出。使用存储过程编写的系统则相对要简单得多？我从来没有看到过易读、易维护的存储过程，难道楼主是在说存储过程只能编写简单的系统？存储过程能够很好地与敏捷开发方法相契合？真弄不明白，存储过程与敏捷开发有什么强关联。
4.把数据库视作一个对象，那么接口是什么呢？SQL？如果把CPU视作一个对象，接口是指令流，是不是就不需要SQL了？
5.所谓术业有专攻，关系数据库只是一个专注于基于索引的数据持久化存取工具，逻辑处理不是它的重点，所以才会使用SQL这么简单的结构化语言。现在官方的、开源的好用的ORM一大堆，需要购买的是服务吧。
6.多层体系需要掌握某种一个框架，对于他们而言只会降低开发成本。对于SQLer而言，短期内加大开发成本是肯定的，因为需要学习新的技能。当然一般来说，用自己熟悉的技术做项目是应该的，但是把自己关在里面就...
反正个人一般能不用存储过程就不用存储过程，那是DBA的领域额改个存储过程都要审批，尼玛，还是程序里好，随便怎么写
数据库的访问机制，是最高效的了，加上索引合理，使得它的效率可以成千上万倍地提高
而应用程序（典型的就是java后台应用）自行实现这些功能，实在是。当然，放在应用程序实现，有一个很大的好处：
应用服务器可以任意叠加，而数据库服务器只能提高单机（包括集群、一写多读）性能
而单机的性能，到了一定程度，再想提高是很困难的了
而机器的叠加，总的性能提高几乎是线性的
这个时候，利用应用程序的好处才体现出来了不过，绝大多数系统达不到这个时候
所以，只会觉得java系统是个“败家子”。
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用
涉及到版权问题 我都花钱买oracle了 为什么还让我花钱买sql server呢
我以前的客户就是 另外还涉及到人家的数据库服务器里面有各种保密的东西 你只能把create table那些语句发给他们的技术人员 你只能用ftp把你的应用考到web服务器下你误会我的意思了
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用这要求产品、项目方同时提供for oracle/for mysql的数据库访问封装
至于不直接在数据库操作，那是很正常的，不是 不用存储过程的 原因
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用
我赞同这个观点，还有就是相同的数据库的不同版本对存储过程的支持也是不同的。再加上搞信息系统开发的一般都是不大的软件公司，如果使用存储过程，那么公司还要养一个专门的负责存储过程的人员，他与其他编程人员是完全不同的，这也增加了项目的风险。
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用
我赞同这个观点，还有就是相同的数据库的不同版本对存储过程的支持也是不同的。再加上搞信息系统开发的一般都是不大的软件公司，如果使用存储过程，那么公司还要养一个专门的负责存储过程的人员，他与其他编程人员是完全不同的，这也增加了项目的风险。如果应用系统的开发者都没人熟悉数据库，那他们开发的系统的运行效率能不慢吗？
数据库方面的优化与否，效率是成千上万倍的差别，用户在硬件上的投入能增加成千上万倍吗？
如果用户不允许安装数据库，说明这个系统与数据库关系不大。
否则，为了适应不同的数据库，是需要同时实现for oracle/for mysql的数据库访问封装，但上层基本不变
否则，完全在应用程序自行实现大表的关联，多投10倍的硬件都没有用这要求产品、项目方同时提供for oracle/for mysql的数据库访问封装
至于不直接在数据库操作，那是很正常的，不是 不用存储过程的 原因我说的意思是把if() {} else {}等写在程序里 不是写SQL的case then 这就是楼主说的问题 有没有必要的问题 不是对错的问题
你说的对 我理解 但是你没理解我和楼主说的意思
我的想法是 复杂的逻辑直接写在数据库 没必要写在程序上
可能是我表达不好 居然还要再解释一次
数据库再怎么优化都是基于硬盘读取的，虽然数据库也有缓存系统，但是不可能具有业务针对性，仅仅就是一个FIFO的查询结果集合，不仅效率低下，而且内存浪费严重。
而应用程序缓存是基于内存的，命中率一般的情况相对于硬盘读取也是成千上万倍的差别，就算是分布式内存缓存也差不多。举个例子，比如1000W普通数据的分页查询，数据库查询一般都是0.1s-0.3s左右，而内存查询是0.00XXXms左右。