@Dream world 梦想天空
改源代码也麻烦啊, 不知道这帮人在想什么. 而且他还说了, 即使将来出sp1, 也不会把这个包含进来, 要下一代的vs 才会支持. 晕死.

@老Q
呵呵, 的确是有这个问题, 不过根据引用的局部性, 一般情况下, 一段时间内应该都会在同一个子文件夹下工作, 跨越两个以上文件夹的机会不应该太多, 所以还可以接受了

@GoGoSonny
已经确认, 果然装了sp1 就好了, 多谢多谢!!

@坚强2002
@longer
不好意思,是我贴示例图片的时候一时大意, 忘写contentTemplate了.

这个我当然是知道的, 而且我也提到了, 我的程序最终是可以正常运行的, 不管是scriptManager 还是Proxy , 或是updatePanel, 智能感知根本不工作, 手写出来提示错误, 在正常的页面上, 即使缺少scriptManager, 写updatePanel 的时候也是有智能感知的, 而且编译也没有问题, 只有在运行的时候才会因为缺少scriptManager 而报错.

@GoGoSonny
谢谢, 可能是这个原因, 这两天太忙, 还没来得及验证, 准备今天装一下试试看.

刚才试过了, 还是不行啊, 你们都没有碰到这样的情况吗?

@徐少侠
"这两种方式其实仅仅是将压力从数据库服务器转移到了应用服务器。整体的系统压力还是在的。" 呵呵, 这个是当然的, 我在这一问题上的观念是: 假设一个需求用数据库服务器来承担是10, 在应用服务器上是20, 也要移到应用服务器上去, 更何况, 实际上我认为在应用服务器上很可能会是5甚至更少.

我之所以说不满主要是你用太多篇幅来证明存储过程好, 似乎你没有认真看我的原贴, 呵呵, 我在原贴中花了不少笔墨来弄清我的立场, 我不想在这里讨论存储过程是不是好于sql语句, 因为我的前一篇已经大量的讨论过了, 并且有人批评说这种争论是"月经博", 每过几个月就会说一次, 让我很汗颜, -----不仅是我, 我想任何人也不会认为存储过程的效率低, 我个人的态度仍然是尽量地不用存储过程, 不过我并不想再继续讨论这一点, 我之所以不愿意用存储过程, 当然是因为其它原因, 而不是存储过程的效率低下.

关于数据库的使用程度, 这才是我关心的point, 如你所说, 我认为数据库只应承担存取数据的工作, 甚至可以说, 使用复杂的sql 语法, 或是数据库附带的其它非数据操作功能, 我觉得这些是"奇技淫巧", 不值得提倡使用. 原因很简单, 出发点仍然是尽一切可能为数据库减轻工作压力.

前面我也说过, 一个工作即使数据库更擅长, 只要有可能转嫁给应用服务器, 就毫不犹豫地转嫁给它, 即使这个工作要增加一倍的代价也在所不惜. 只让数据库做它最基本, 最擅长的工作, 它肯定会做得更快更好.

@徐少侠
说句实在话，对你的评论很不满......你花了一半篇幅证明存储过程的效率高于sql语句, 难道我有在任何时候说过, 存储过程的效率低了么?

你的后一半篇幅跟我所讲的主题也没有任何关系, 不知道你为什么会以此为论据来批评我, -----我不是听不得批评, 只不过被批得有点莫名其妙, 呵呵.

"数据库是一门博大的技术", 这是当然, 由于涉及的东西太多, 所以不可能把"数据库" 当做话题来讨论, 否则会死人的. 在这里我只是想旗帜鲜明地反对很长的, 包含了业务逻辑的存储过程.

@xiaotie
我不能同意你的观点, 不过也不再就这个问题再讨论下去了, 原来是我的话没说清楚, 我已经更新了主贴, 呵呵.

@Jeffrey Zhao
嗯, 是的, 如果调用存储过程只需要一次, 而提交sql 语句要好几次, 那肯定是不可取了, 现在暂且认为, 无论调用存储过程, 还是提交字符串, 都是只有一次, 或者说, 如果要多次提交, 则都需要多次, 公平起见么, 呵呵.

举个例子吧, 前天有个叫"简爱" 的, 也写了篇文章, 您好像也看过了吧, 他所写的那个分页的存储过程, 我认为就是反面的典型. 呵呵.

以下是我关于分页对他的回复:
@简爱
对于分页, 一般情况下, 能够预料到表中的数据有多少行, 如果行数不太多, 可以一次读出, 保存在session中, 这样换页的时候, 就直接从session 取数据就行了.

对于行数非常多的表, 采取更复杂的折中策略, 类似于缓冲策略, 假设表中有100万条记录, 先获取这个count, 让客户端知道一共有多少条, 然后读出一个固定的长度, 如5000条, 保存在session中, 如果用户请求5000条以后的, 再去读取相应的5000条, 一般情况下, 用户会顺序地请求数据, 所以直接取session就行了. -----实际上, 对如此大的表, 用户不太可能会请求所有的记录, 这种缓冲策略会极大的缓解数据库服务器的工作.

@Clark Zheng
:-)

@邹健
我觉得这主要是一种观念, 或者像"代码大全" 里说的, 是一种"隐喻", 而这种隐喻在很大程度上会左右写代码时的决定.
我自己怎么想都觉得这种观念是对的, 不过似乎确切地赞同我的人不多.

@Jeffrey Zhao
是的, 当然, 查询肯定是主要的部分, 问题在于, 这部分代价是不可避免的, 现在服务器压力沉重的条件下, 我的出发点是, 尽可能把一些不必要的东西抛开, 只留下这些最必要的. IF ELSE 什么的, 当然不会带来什么问题, 只不过, 在实践中, 我见过的存储过程大都很庞大, 动辄都近百行, 里面非查询的含量已经不少了, 对某一个存储过程来说, 当然, 它们的比例仍然很小, 但是, 存储过程太多, 执行的次数又频繁, 我想就不能再简单的忽略它们了.

至于连接的次数, .net framework 实际上会自动维护一个连接池, 在代码里关闭的连接, 实际上仍然是打开的, 下次仍然会使用它, 如果实在不放心的话, 可以自己在代码里再加一层连接池, 这样就可以确保连接不会被频繁地打开关闭了.

@邹健
其实你的第一种方法封装程度很低了, 感觉区别不大, 经典的存储过程会把这个判断逻辑封装进去, 成为这样的形式:
if (ExecProcedure("IsHavePrivilege("userA")")) ......
而我更倾向于这样处理:
sql="select a.userName,b.userName from users a inner join oldUsers b on a.userId=b.userId" ;
ExecSql(...out dt...);
if(dt==null || dt.rows.count<1)......

真是活见鬼了, 我只发布了一次, 不知道为什么会冒出来四篇, 这篇文章在草稿阶段待的时间比较长, 有几个小时, 莫非是这期间的自动存草稿的动作, 在最后都被发布了?

@OK_008
五笔学起来确实费劲, 不过你说不见得比拼音快, 就有点......-----我只是业余的五笔使用者, 打字速度可达到170字/分, 我就没见过用拼音的能达到这个速度, 呵呵.

@Sleet
"还有G级的系统，应该规划用存储过程来实现（个人意见）"
能否详细说明一下理由?

我现在主要想知道的是, 对于10句, 或者说5句以内的sql 语句, 至少是能转化成这种简单sql语句 的情况, 是否应该尽量避免使用存储过程 .

对于企业级应用来说, 大量的报表, 数据维护页面, 实际上用到的sql 语句都不会需要很多句, 真正复杂的sql 段, 多半与用户没什么关系, -----举例说明吧, 比如在系统中, 创建一个用户, 一个用户登陆的时候, 去检查他的权限, 这样的动作, 我们系统目前的做法是用存储过程 , 不用说, 在存储过程中, 包含大量的逻辑检查, 而我认为这只是徒然增加了数据库的压力, 应该改写成嵌入式sql 语句, 像类似这样的情况举不胜举 .

@Sleet
...... 还是没弄明白你为什么会这么说, 你的意思是: 使用了存储过程就可以顶得住, 而不用存储过程, 就会顶不住, 是这个意思吗?

@Kingthy
同意.

@Sleet
我不在软件公司工作, 我公司的ERP 就是我们自己编写, 自己维护的, 所以升级的时候无需找别人, 既然升级程序, 打开工程->修改->编译, 这是当然的了, 怎么可能指望不用重新编译项目而使其升级? 很小的细节升级是不应该的, 这说明当初的需求分析做得太不到位了, 一旦升级系统, 基本上改动都不可能是几句代码那么少.

我们公司的数据日增量也可能达到G 级, 不过我没看明白你 的意思, 为什么我的程序会顶不住? 在大数据量的系统环境下, 谁是瓶颈? 这也是我的主要指导思想之一, 就是我在文中所说的, 数据库服务器是压力最大的服务器, 由长长的sql 段构成的存储过程会给数据库服务器带来很大的负担, 所以我想尽量去减轻它的负担, 能由web 服务器处理的, 就由web 服务器处理. 临时表用得不多, 而且, 临时表也不能是主要原因吧?

@韩现龙
这个, 我不认同, 我绝对相信你看到的时间差, 但是, 同样的语句, 我每次执行得到的时间都不一样, 差别可以达到近十倍, 而且, 如我在文中所说, 存储过程跟普通语句之间的差异只是差别在编译时间, 对于编译后的sql 语句来说, 其执行时间应该等同于存储过程 , 跟表的规模没有关系.

@古巴
你说的确实有道理, 不过对于一次升级来说, 虽然理论上可以认为只改一下存储过程就行了, 但是实际上基本不可能只改那一点, 一定会有附带的其它东西要改, 所以重新编译程序在所难免, 我所指的扩展性好, 主要是基于存储过程可能会被多个页面所调用, 这样修改起来风险会很大, 因为改的时候很可能记不清到底有哪些页面调用了这个存储过程, 尤其是在公司里人员变动时, 后来的人基本上不敢轻易改以前的存储过程, 害怕会对其它部分有影响.

另外, 通过在程序中把表映射成类, 可以很好地把sql 语句类型化, 这样如果表结构发生变化, 只要更新映射, 就可以把所有的旧引用变成编译时错误, 而不会是运行时错误. 这也是一个极其重要的原因. 存储过程把表结构焊死了.

@Jeffrey Zhao
是的, 我参与的项目里都没有对外公开存储过程/视图 等的, 如果要公开, 那么区分用户就非常重要了.

@Wuye
同问, 耗时的操作耗的是执行时间, 磁盘IO 有那么多, 不论存储过程还是内嵌语句都偷不了懒, 为什么要放存储过程?

@Anders Cui
没错, 我所知道的是, "远看泰山黑乎乎", 呵呵.

to @gxh973121
呵呵, 其实我以前看见过, 不过当时懒得改, 现在又被你发现了, 汗一个, 现在已经更正. 谢谢.

to: 浮云
谢谢, 仔细检查一遍, 果然发现有问题, 在一定条件下, 会造成金额未完全初始化, 已经更正.

呵呵, 拐卖未成年少女确实不是好买卖.
我最多赚到2000亿, 花了好长时间.

to: 浮云:
游戏结束后金钱还在累计? 汗, 这么严重的bug? 我没发现啊, 能详细描述一下问题么?

;-)

其实我觉得一行也够用了, 毕竟这只是一种辅助手段, 不可能指望在批处理中操作大量文本, 批处理毕竟不是编程语言啊, 呵呵 .

谢谢支持.

set /p 指令用于将用户输入的一行赋值给一个变量, 例如:
在命令行中输入"set /p a=", 然后回车, 命令行就会等待用户输入,
输入完毕后敲回车, 完成对变量的赋值.

这里利用这一点把输入重定向到文件, 所以只能读取一行, 如果发现
有换行符, 就发生赋值错误, 所以就会无效.

to：@Vincent Yang
呃......我没有看到。

呵呵， 原来如此， 谢谢指教。
博客园的高人就是多啊， 看来搬家搬得太对了。

to: @Jack Niu
太谢谢你啦!
真不知道还可以这样访问.

我是把这个类放在一个独立的文件中的, 而不是放在页面的代码里, 所以不能直接用session.

真晕, 我原来的通用类里都是把response, request 这些东西作为参数传过来的, 真是... 唉~~ 呵呵 , 再次感谢!

to: @MadGoat

没有错啊, 那个"<" 不是多写的, 你再试一下吧.

如果要把当前日期的样式区别出来呢, 该怎么做?
就是, 比如今天是8/31, 则8/31 号这一天应该有一个单独的样式, 一下就看出这是今天. ----谢谢~

另外想问一下, 你是怎么贴出这种可以折叠的代码的? 是你的博客直接提供这种功能, 还是需要自己编辑HTML? 谢谢

不错, 支持~