存储过程，你怎么不去死！严重误导广大程序员
    首先声明，本人没分，所以结贴的时候可能会给出无满意给分（我想不结贴，但不结贴好像不让我发表新帖），所以大家凭良心发帖吧。     
    很多人觉得存储过程很重要，为什么呢？因为它比较难以掌握，哈哈，多么荒唐的理由，难的就是重要的？非也！多么愚蠢的一个命题，存储过程严重误导了广大程序员。让我谈谈自己的观点。
       在MVC时代以前，程序系统的层次分的不算很严谨，存储过程有一些优点，比如，只需一次编译，运行速度快等，它得到了广泛的应用，但遗留下来非常严重的问题到今天：维护极不方便！大家不知道维护过10年前开发的包含大量存储过程的系统没？如果你维护过，那请你告诉我你的感受！维护方便么？你敢去修改里面的代码么？你敢修改一下数据库表的结构么？这个系统易于扩展么？系统层次结构清晰么？答案都是否定的！这些问题在以前可能还不算太严重，但在今天看来全部都是致命的！今天的程序对于简洁是宗教般的追求，易维护，易扩展是两个非常重要的开发理念。
       进入MVC时代以后，时至今日，系统分层理念已早日深入人心，是事实上的“开发铁律”，其神圣性不容侵犯！分层理念认为：系统分层是易于维护和扩展，各个层次之间耦合度尽量降低，各层的职能分配明确。这种观念与存储过程是严重违背的，几乎“水火不相容”，比如MVC分层：与数据库接触的DAO层和处理业务逻辑的业务层，数据库层只负责于数据库简易操作，它只应该包含增删改查四个方法，不应该有第五个多余的方法！任何与业务逻辑相关的操作处理必须分那个在业务层来实现。关于分层的好处，我在这里就用多说了，它应该成为程序员的圣经，神圣不容侵犯。那么，well,存储过程？它是什么东西？它是包含着业务逻辑相关的数据库操作！它应该出现么？它算DAO层还是算业务层？弊端就显现出来了，这种把业务逻辑包含在数据库操作之中的存储过程对于以后维护是非常致命的，它违背了分层思想，违背了各层职责清晰的思想，是历史遗留的糟粕。
      存储过程时至今日表现出来的弊端已经远大于其利端，至少目前我接触的MVC分层系统早已见不到存储过程的踪迹，假如再来讨论存储过程和MVC分层各自的优缺点，我认为那是对MVC分层理念的侮辱。
      当然，本人水平有限，欢迎广大前辈给予指导。

------解决方案--------------------
呵呵！
------解决方案--------------------
呵呵！
------解决方案--------------------
车本无好坏之分，但你开车去杀人和开车就救人完全是两回事。
------解决方案--------------------
.
------解决方案--------------------
..
------解决方案--------------------
那么，well
------解决方案--------------------
太过绝对了。。。。
不想说什么了。
一个MVC的狂热分子。
无证。
------解决方案--------------------
凡事无绝对

------解决方案--------------------
说的太绝对了。
------解决方案--------------------
再说LZ你怎么知道MVC就是架构的最终形态呢？10年后的人们说不定也会对维护你写的MVC程序大呼头疼呢
------解决方案--------------------
简单说，数据库做的应该是数据库应该做的，数据库应该做的不单单是增删改查四个方法。

退一步，就算数据库就是增删改查四个方法，数据库表之间是有关联的，没有关联的数据就是一堆垃圾，既然有关联拿操作上就会有事务性......

不愿多说了，不愿绕口令
------解决方案--------------------
说白了.公司缺少资源.DBA不就是专门干这事的吗?交付给他弄.
------解决方案--------------------
.
------解决方案--------------------

引用:

.

你喜欢.
------解决方案--------------------
没什么好说的了。。。你感觉维护存储过程难。。。。。如果是10年前的sql语句写出来你一样说难维护。。。。
------解决方案--------------------
同感，支持
------解决方案--------------------
sdf
------解决方案--------------------

引用:

简单说，数据库做的应该是数据库应该做的，数据库应该做的不单单是增删改查四个方法。

退一步，就算数据库就是增删改查四个方法，数据库表之间是有关联的，没有关联的数据就是一堆垃圾，既然有关联拿操作上就会有事务性......

不愿多说了，不愿绕口令

表之间关联是不得已而为之的设计，如果一个系统各个表之间没有关联，那是非常完美的，本人接触的日本开发的系统里面有近300个表，很多表的字段均在150个以上，但表之间关联度很低，即使有，也只存在一个外键关系，这就是理念：宁可多设计几个表，也不设计关系复杂的表！再者，表之间的关联的处理也必须放在业务层。
------解决方案--------------------
存在即合理。

------解决方案--------------------