浏览主题：????????????????????????????????????网招???
主题：????????????????????????????????????网招???
同样的数据库结构 只不过，带存储过程的适合大型应用，可以进行比较好的负载均衡，有比较好的系统结构。另外，存储过程是编译的，性能稍好。 偶是这样认为的？你们呢？ 编辑标志 本帖最后由［自在的尘］在 2007-4-9 10:46:39 编辑 |
|
群里的帖上来就差不多了。。 |
|
看到很多拼串的PROC，最后exec @sql 把逻辑都写进PROC，加重db server负担 |
|
确实，把聊天记录发上来就行了， 我去找。 |
|
叶子 10:48:30
个人觉得差距不是想像中的那么大。 再说程序也要看谁写的。。。 另貌似和负载均衡关系不大。。 星╄Lucifer 10:48:37 纯性能上的, 讲起来, 很多地方 我是说不清楚. 至少我没有详细测试过 或者见过文档 星╄Lucifer 10:48:48 但是 可能最明显的 是一个 来回的数据交互上 叶子 10:48:53 恩。 星╄Lucifer 10:48:55 假设 你就是一个 select 可能没差别 叶子 10:49:20 比如论坛。发一个帖。更新几个表。再输出。 星╄Lucifer 10:49:20 但是有些逻辑判断或者一些别的 你放到程序里 然后再回来... 这样产生的 消耗 才是正够大吧 叶子 10:49:36 存储过程传一次。返回一次就ok sql语句你要几次。。 叶子 10:49:40 这个差距还是有的。 自在的尘 10:49:53 eeee 自在的尘 10:50:01 负载， 自在的尘 10:50:13 知道了，偶有计较了， 自在的尘 10:50:28 刚才我只想到负载、性能方面，用存储过程的要好点， 叶子 10:50:56 好点是应该的。。要不这些厂商都发痴了么。。 星╄Lucifer 10:51:31 但是 这应该也是无可奈何吧 星╄Lucifer 10:51:37 唔 . 好处是有不少, 不过可能从结构或者一些其他的程序上,多少还是有点麻烦的. 会把一些逻辑分拆到库里面去,或者有些时候两边都需要更新的时候会比直接的麻烦一些. 星╄Lucifer 10:51:52 访问爆发的话 , 有时候你用硬件顶都顶不过去呢 自在的尘 10:51:54 两边都需要更新? 星╄Lucifer 10:52:14 比如说程序要更改一些 . 程序要改, 存储过程也要改 星╄Lucifer 10:52:17 那是很正常的吧 叶子 10:52:19 过程里面的逻辑改了。。程序的逻辑也要改。。 自在的尘 10:52:22 就是可以把一些逻辑拆到库里去， 这样有可能增加服务器负担 星╄Lucifer 10:52:30 叶子 10:52:32 没多少逻辑的。。。 自在的尘 10:52:34 这个是接口定义 星╄Lucifer 10:52:34 这样是降低好不好. 叶子 10:52:43 大运算不会丢里面去的 自在的尘 10:52:51 只要定义好的接口了 能最大限度的降低修改量 叶子 10:52:53 几个if else还不至于。。 自在的尘 10:53:00 总比程序里一直用SQL好 星╄Lucifer 10:54:02 实际时候 计划总是比不上变化啊 星╄Lucifer 10:54:32 比如公司里这次就彻底的给变化了一下. 以头抢地ing |