存储过程，你怎么不去死！严重误导广大程序员首先声明，本人没分，所以结贴的时候可能会给出无满意给分（我想不
存储过程，你怎么不去死！严重误导广大程序员
首先声明，本人没分，所以结贴的时候可能会给出无满意给分（我想不结贴，但不结贴好像不让我发表新帖），所以大家凭良心发帖吧。
很多人觉得存储过程很重要，为什么呢？因为它比较难以掌握，哈哈，多么荒唐的理由，难的就是重要的？非也！多么愚蠢的一个命题，存储过程严重误导了广大程序员。让我谈谈自己的观点。
在MVC时代以前，程序系统的层次分的不算很严谨，存储过程有一些优点，比如，只需一次编译，运行速度快等，它得到了广泛的应用，但遗留下来非常严重的问题到今天：维护极不方便！大家不知道维护过10年前开发的包含大量存储过程的系统没？如果你维护过，那请你告诉我你的感受！维护方便么？你敢去修改里面的代码么？你敢修改一下数据库表的结构么？这个系统易于扩展么？系统层次结构清晰么？答案都是否定的！这些问题在以前可能还不算太严重，但在今天看来全部都是致命的！今天的程序对于简洁是宗教般的追求，易维护，易扩展是两个非常重要的开发理念。
进入MVC时代以后，时至今日，系统分层理念已早日深入人心，是事实上的“开发铁律”，其神圣性不容侵犯！分层理念认为：系统分层是易于维护和扩展，各个层次之间耦合度尽量降低，各层的职能分配明确。这种观念与存储过程是严重违背的，几乎“水火不相容”，比如MVC分层：与数据库接触的DAO层和处理业务逻辑的业务层，数据库层只负责于数据库简易操作，它只应该包含增删改查四个方法，不应该有第五个多余的方法！任何与业务逻辑相关的操作处理必须分那个在业务层来实现。关于分层的好处，我在这里就用多说了，它应该成为程序员的圣经，神圣不容侵犯。那么，well,存储过程？它是什么东西？它是包含着业务逻辑相关的数据库操作！它应该出现么？它算DAO层还是算业务层？弊端就显现出来了，这种把业务逻辑包含在数据库操作之中的存储过程对于以后维护是非常致命的，它违背了分层思想，违背了各层职责清晰的思想，是历史遗留的糟粕。
存储过程时至今日表现出来的弊端已经远大于其利端，至少目前我接触的MVC分层系统早已见不到存储过程的踪迹，假如再来讨论存储过程和MVC分层各自的优缺点，我认为那是对MVC分层理念的侮辱。
当然，本人水平有限，欢迎广大前辈给予指导。
[解决办法]
呵呵！
[解决办法]
呵呵！
[解决办法]
车本无好坏之分，但你开车去杀人和开车就救人完全是两回事。
[解决办法]
.
[解决办法]
..
[解决办法]
那么，well
[解决办法]
太过绝对了。。。。
不想说什么了。
一个MVC的狂热分子。
无证。
[解决办法]
凡事无绝对
[解决办法]
说的太绝对了。
[解决办法]
再说LZ你怎么知道MVC就是架构的最终形态呢？10年后的人们说不定也会对维护你写的MVC程序大呼头疼呢
[解决办法]
简单说，数据库做的应该是数据库应该做的，数据库应该做的不单单是增删改查四个方法。
退一步，就算数据库就是增删改查四个方法，数据库表之间是有关联的，没有关联的数据就是一堆垃圾，既然有关联拿操作上就会有事务性......
不愿多说了，不愿绕口令
[解决办法]
说白了.公司缺少资源.DBA不就是专门干这事的吗?交付给他弄.
[解决办法]
.
[解决办法]
你喜欢.
[解决办法]没什么好说的了。。。你感觉维护存储过程难。。。。。如果是10年前的sql语句写出来你一样说难维护。。。。
[解决办法]同感，支持
[解决办法]sdf
[解决办法]表之间关联是不得已而为之的设计，如果一个系统各个表之间没有关联，那是非常完美的，本人接触的日本开发的系统里面有近300个表，很多表的字段均在150个以上，但表之间关联度很低，即使有，也只存在一个外键关系，这就是理念：宁可多设计几个表，也不设计关系复杂的表！再者，表之间的关联的处理也必须放在业务层。
[解决办法]存在即合理。
------解决方案--------------------
十年后再来看看你的多层结构，里面的业务你敢改吗？数据库里没业务逻辑了吧，里面的表你敢动吗？
不管你用什么结构，做好文档，写好注释才是最主要的
[解决办法]请楼下继续辩论！
[解决办法]标题很吸引人
[解决办法]在单纯的rdbms也许是如楼主所说。
不过提供了编程能力的rdbms已经不是单纯的rdbms，他也是很有能力承载逻辑的，数据结构本身就是一个m，存储过程、函数提供了c的途径，甚或你用的 企业管理器 他本身不就是一个“v”?
所谓的mvc的c，自然也可以放在数据库实现，我想写个mvc程序只有一个view是用java写的也是我的自由。难道一定要用项目所用的语言封装完了才能叫mvc？无非是你用的mvc框架都没把c放数据库而已。
谁规定mvc就一定不能在数据库上多点逻辑？
在极端的情况下，追求所谓mvc可能是一种罪恶：
如果我要做个一百万笔记录加1的操作，我为了所谓的纯净mvc因此和数据库做了5百万次的交互我会坐立不安的：原来一台服务器就搞定了，结果用3台用户还天天喊死机了~~~~~~~~~
[解决办法]lz头像太适合了
[解决办法]不是在.net版发过 又到这发勒
还是4个字 一笑而过
[解决办法]哈哈
[解决办法]飘过。。！
[解决办法]大家说的，都对！
这不是错，也不是问题！
===========================
只是，现在是个公司，开发一个东东！就想多干点别也能干的事！
只是支持，所以，让家看了，说这个也能干，那个也能干！
===========================
没有必要争，你不用不就完了！
取之利，舍之弊！才王道！
[解决办法]仅仅围观
[解决办法]像我们做pb开发的不用存储过程用什么
笑话。mvc是最终形态吗？？？、
[解决办法]mark,好久没用数据库编程了，学习了
[解决办法]首先我声明，这次发言是出于个人观点，也是想跟楼主分享一下自己的经验，我研究数据库也有几年了，有时候可以来我博客看看sufei.cnblogs.com 或者cckan.net Csdn的也行。楼主给我的感觉是有那么一点点的情绪感在里面，看问题可能缺少一点客观性，对于楼主的问题我一一作下分享
楼主第一个观点“大家不知道维护过10年前开发的包含大量存储过程的系统没？”
10年开发的程序不是因为写存储过程而难于维护，有很大一部分是因为技术过时。还有就是设计思路过时，可能最可怕是需求过时吧。这些其实与使不使用存储过程并没有太大关系。
楼主观点二“维护方便么？你敢去修改里面的代码么？你敢修改一下数据库表的结构么？”
我个人感觉一个系统方便 不方便 维护，关键在程序本身的设计上，而并不在于存储过程。像你说的修改表要结构这个好像你不和是写Sql代码和写存储过程都不太好维护吧，而我个人感觉定存储过程的话只需要修改存储过程就行了，如果你写Sql代码的话，你不但要修改数据库，还要修改代码，这样的话成本就高了，本来是一个Dba的工作，你要多招一个程序员了。
楼主观点三“这个系统易于扩展么？”
系统易不易于扩展这个就更与存储过程无关了，存储过程本身也是Sql代码，你写可以写成类写成公共的函数，不一定非要一个存储过程完成一个功能的。也是可以规划的。
楼主观点四“系统层次结构清晰么？”
这个可能是楼主仅限于自己熟悉的Mvc吧，而且应该是你最常 用的MVC的模式，其实MVC的变化还是很多的，也些是你的现况的问题
个人观点：
存储过程我认为如果不使用只以下几种情况
1.数据库本身不支持，这个谁也没有办法
2.数据库代码非要求一套而且适合多种数据库
3.程序员本身不擅长，或者认为不好，或者是习惯了Sql语句的写法。
其实大家细心的看一下就会发现，C#中除了对接Sql语句是直接执行的Sql语句，其它的.net是编译成存储过程执行的。
