针对这个问题再写一篇文章讨论, 自己也觉得多余, 不过, 由于上一篇中我表意不清, 同时掺杂了一点我对存储过程的不满, 导致整篇文章的中心意思偏离了主题, 在讨论的过程中, 更是越偏越远, 到最后, 连我自己都几乎忘了我的本意. 因此, 觉得有必要再次阐述我原本的立意.

自杀用长枪好,还是用短枪好? 我的回答是, 不要自杀. 这个回答并不真的是客观地评论哪种枪更适合于自杀, 而是, 我根本不关心这件客观的事情, 我的态度是从另一个角度, 说这件事情根本不该发生. 同样的, 其实对于存储过程和sql 语句, 我并不是想去真的挑起它们之间谁更优秀的争吵, 而是说, 在多数情况下, 根本不该去写那样的存储过程.

是的, 我绝对承认, 对于几十几百行的存储过程 , 如果把它们拼成字符串由web端提交, 效率肯定会大大低于存储过程, 而我想说的是, 这几十几百行的存储过程, 应该换成一行sql 语句, 其它的部分, 不要由数据库来处理.

这个结论, 以及所有的讨论, 所基于的环境是:
<1>局域网. 所以写公网程序的兄弟就不要把公网的限制也考虑进来了.
<2>数据库服务器比较繁忙.

在日常的应用中, 查报表是最慢的, 因为报表的需要是千奇百怪的, 有的报表纵深要汇总一个月,甚至几个月的数据, 横向要连接几十张表, 查询一次甚至会需要超过一分钟, 而由于在这期间数据库忙于处理这个查询, 必然会延迟其它的请求, 这种交通堵塞效应在每月特定的时候(报表查询高峰) 会极其严重.  即使在平时, 系统的响应速度也几乎完全取决于数据库服务器的响应时间.

以上这么多, 只为了说明一点: 系统的响应时间99%由数据库服务器响应时间决定.  如果不同意这一结论, 就没什么可谈了, 因为我除了亲自工作过的三家公司外, 还听说,见过好几家大公司的情况, 都是这样的, 这是讨论下去的前提.

有了这个前提, 才有后面的结论, 必须尽一切可能减轻数据库服务器的工作量, 某一个报表查询时间如果能缩短0.5秒 , 那整体效应可能就是数分钟, 因为这一个查询早结束0.5秒, 其它的请求就可以早点被处理, 否则交通会越来越堵.

而大量包含业务逻辑的存储过程, 就是增大数据库服务器压力的元凶, 如果把一段50行的存储过程, 改成一个select 语句, 中间的差别多大, 我想不言自明. 

写到这里也就够了, 再写下去, 就又回去存储过程跟内嵌sql谁更好的怪圈了.

[2007/11/2 更新:]
我从来没有对自己的表达能力如此地自卑过, -----唉, 我看我有必要考虑是否要撞墙了.
wangyh 兄一针见血地指出了我关心的问题, 不是内嵌sql VS 存储过程, 而是SQL VS C#, 这才是关键.
xiaotie 兄的论断, 我并不同意, 不过我就不再做进一步的辩论, 因为我现在发现多说一句都可能使问题偏离中心. 既然他质疑我的"如果把一段50行的存储过程, 改成一个select 语句, 中间的差别多大, 我想不言自明. " 这句话, 我就把它改成, 把一段50行的存储过程, 改成只有一句的存储过程, 这应该没有问题了吧?

为了不使sp 派误会, 就假设程序中完全不出现sql 语句, 即使只有一句, 也写成存储过程, 但是, 这些存储过程都不包含逻辑处理, 而是都由C# 去负责, 也即我的标题, 存储过程是长枪, 内嵌sql 是短枪, 逻辑处理是自杀, 我现在不想讨论究竟谁更适合去做逻辑处理, 而是, sql 语言根本不要去做逻辑处理, 只要有可能用C#做的, 都用C#去做, 而不放在sql 语句中.

之所以会从这个讨论变成存储过程vs 内嵌sql, 原因在于, 当写存储过程的时候, 更可能会"不知不觉", "自然而然" 地把逻辑处理写进去, 而写嵌入式语句时, 更可能会把相应的处理用C# 实现. 

应该没有歧义了吧?