- 浏览: 18106 次
- 性别:
- 来自: 深圳
最新评论
-
qq1988627:
一个可以吧tomcat jvm空间设大点,二,如果报表是在服务 ...
老系统比较慢,从那些方面着手! -
javabrother:
mercyblitz 写道<div class= ...
开发中的困惑! -
mercyblitz:
<div class="quote_title ...
开发中的困惑! -
坏孩子:
<div class="quote_title ...
开发中的困惑! -
aws:
<div class="quote_title ...
开发中的困惑!
来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。
不知道前辈们怎么看的。谢谢!
评论
31 楼
javabrother
2010-07-30
mercyblitz 写道
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。
不知道前辈们怎么看的。谢谢!
</div>
关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:
1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。
2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。
3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。
4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。
5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。
</div>
1. 用预编译
2. 生产环境一般都很牛逼,而且有专职dba调优
3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧
4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了
5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。
</div>
1.预编译一定能够提高性能?
2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。
3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。
4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。
5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:
http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages
在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。
如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。
</div>
1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。
2. 没用过你说的那些,我不解释这个问题
3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。
4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点
5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好
6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器
</div>
1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。
2.3不说啦。
4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。
5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。
至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。
启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。
6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。
</div>
5.
你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。
oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。
存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?
</div>
这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt="">
</div>
你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了
</div>
不是,讨论方向错误啦。这里的前提是SQL,不是存储过程。
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。
不知道前辈们怎么看的。谢谢!
</div>
关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:
1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。
2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。
3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。
4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。
5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。
</div>
1. 用预编译
2. 生产环境一般都很牛逼,而且有专职dba调优
3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧
4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了
5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。
</div>
1.预编译一定能够提高性能?
2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。
3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。
4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。
5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:
http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages
在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。
如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。
</div>
1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。
2. 没用过你说的那些,我不解释这个问题
3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。
4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点
5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好
6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器
</div>
1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。
2.3不说啦。
4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。
5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。
至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。
启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。
6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。
</div>
5.
你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。
oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。
存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?
</div>
这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt="">
</div>
你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了
</div>
不是,讨论方向错误啦。这里的前提是SQL,不是存储过程。
这位哥哥正解,持久层用的ibates,sql都写在xml里面。
30 楼
mercyblitz
2010-07-28
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
</div>
<p> </p>
<p>你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了</p>
<p> </p>
</div>
<p>不是,讨论方向错误啦。这里的前提是SQL,不是存储过程。</p>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
</div>
<p> </p>
<p>你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了</p>
<p> </p>
</div>
<p>不是,讨论方向错误啦。这里的前提是SQL,不是存储过程。</p>
29 楼
坏孩子
2010-07-28
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
</div>
<p> </p>
<p>你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了</p>
<p> </p>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
</div>
<p> </p>
<p>你真的以为动态sql会导致存储过程重新编译?如果不是,请问java执行sql不需要重新解析sql?你的话我看不懂了</p>
<p> </p>
28 楼
aws
2010-07-28
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p><br>对于围绕单表进行的某些互联网应用可能没啥,但是对于多数企业应用,</p>
<p>一般来说需要扔到存储过程里的逻辑,并不是用noSQL之类的可以解决的</p>
<p> </p>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p><br>对于围绕单表进行的某些互联网应用可能没啥,但是对于多数企业应用,</p>
<p>一般来说需要扔到存储过程里的逻辑,并不是用noSQL之类的可以解决的</p>
<p> </p>
27 楼
mercyblitz
2010-07-28
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
</div>
<p> </p>
<p>这里并不是说能不能banding的问题,编译动态SQL相当于重新编译被修改后的源代码一样。从实现的角度,并不存在问题。<img src="/images/smiles/icon_biggrin.gif" alt=""></p>
26 楼
坏孩子
2010-07-27
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
</div>
<p> </p>
<p>5.</p>
<p> </p>
<p>你用其他语言也不是一样要反复编译sql吗?oracle 存储过程的动态sql也可以绑定变量。</p>
<p> </p>
<p>oracle支持的sql,有很多函数是可以提高效率的,所以很多时候不可比避免使用。</p>
<p> </p>
<p>存储过程各个数据库是不一样,但你比较的角度是不对的。每个数据库都有一套解释引擎,这就跟java与.net一样,从来没有说过要标准,只不过是互相竞争。难道你还想从java迁移到.net?</p>
25 楼
mercyblitz
2010-07-27
piao_bo_yi 写道
javabrother 写道
firehoo 写道
那位写3000多行sql的兄弟如果跳槽了,让一个新来的改他的这段代码,那个新来的会不会觉得郁闷?
这个sql是台湾的一个同事写的, 它们写的sql 先把sql语法和关键字写出来,在填条件。这个方法我受教了,以前自己写的sql是 从左到右的写,现在看起来很傻,花的时间review比较多。现在的这种写法虽然看起来很傻,但是写出来的东西很规范的,一看就懂,sql关键字做一行,查询的每个字段做一行,每个条件做一行。往往不会出错!
求例子,没听明白。他们不是一行么 ?
它应该是指类似工具的Format的功能,比如:
SELECT
id,
name,
age
FROM
persons
WHERE
id=?
24 楼
mercyblitz
2010-07-27
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
</div>
<p>1.即使是Oracle,也不是所有场景的预编译都执行良好,比如动态参数的问题,见5条。</p>
<p> </p>
<p>2.3不说啦。</p>
<p> </p>
<p>4.你说得没有错,可能我们面临的项目不同。我经常评估不同的数据库,呵呵,主要是预算的问题。比如,非机密的信息,不会用Oracle这种的商业的。Yahoo!的架构中,也是多种数据库部署的。</p>
<p> </p>
<p>5.多变参数主要是指,在业务逻辑中可能传输多对数据。比如INSERT INTO table_1 VALUES (参数列表),这个参数列表不是固定的,因此动态的参数会性能。就是因为它有shared pool,因此多变的SQL语句会影响Cache击中,因此反复编译,从而影响性能。</p>
<p> </p>
<p>至于标准化,比如SQL有SQL99,SQL03等标准,这些标准得到流行的数据库支持,比如Oracle9i支持SQL99等。但是存储过程,是各异的。</p>
<p> </p>
<p>启动时间长的问题,其实很好解决,中间做一个数据层,利用协议访问。</p>
<p> </p>
<p>6.可能误会啦,我的意思是说,很多地方不要使用存储过程。我了解的银行项目,都是存储过程实现。在早期的架构中,我们也使用了全部存储过程。后来,建议去掉了不少。至于原因,主要还是需求决定的。</p>
23 楼
piao_bo_yi
2010-07-26
javabrother 写道
firehoo 写道
那位写3000多行sql的兄弟如果跳槽了,让一个新来的改他的这段代码,那个新来的会不会觉得郁闷?
这个sql是台湾的一个同事写的, 它们写的sql 先把sql语法和关键字写出来,在填条件。这个方法我受教了,以前自己写的sql是 从左到右的写,现在看起来很傻,花的时间review比较多。现在的这种写法虽然看起来很傻,但是写出来的东西很规范的,一看就懂,sql关键字做一行,查询的每个字段做一行,每个条件做一行。往往不会出错!
求例子,没听明白。他们不是一行么 ?
22 楼
坏孩子
2010-07-26
jychenok 写道
我们是单行数据hql,小数据量sql,大数据量存储过程,赞同小粒度简单sql的观点,就算是oracle也是有bug的,有些复杂用法会不稳定的出现问题...我就遇到过左连接+窗口函数出现bug.多出好几万条数据...
我也碰到过,也是窗口函数套了几层,用了个视图,几张分区表,最后oracle生成了错误的执行计划
21 楼
坏孩子
2010-07-26
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p> </p>
<p>1. 在oracle上是可以的,oracle对sql进行比较,然后找到相应的执行计划,其他数据库我不知道。</p>
<p>2. 没用过你说的那些,我不解释这个问题</p>
<p>3. 解释型语言的确有这个问题,我已经在第一点说明了,数据库可以先找到缓存的执行计划。我理解的楼主的更好的预编译是指更好的执行计划,不知理解是否有误。</p>
<p>4. 我从来不考虑迁移数据库。迁移数据库不仅是sql上的修改,还有数据库其他的机制,比如锁,你有考虑过吗?成本不是一点点</p>
<p>5. 第一,我不考虑迁移数据库。第二,很不好意思,我们的开发团队中有不懂java的,但是没有不懂存储过程的。第三点我看不懂你在说什么,多变输入参数或者我没用过,修改sql需要重写编译存储过程?牺牲性能我很不理解,除非你在生产环境上,并且在业务量高峰时段进行编译,事实上我们这里这是不允许的,另外如果全部写在java里面,你是不是要重启服务器,浪费的时间更多。当然你硬要说会影响,的确有,在编译好以后第一次使用这个存储过程的时候需要解析存储过程并放入shared pool,这也仅仅是第一次。对于常用的存储过程完全可以pin入内存。另外我不懂你说的标准化指什么,非要一套框架么?编码规范就好</p>
<p>6. 我没说过一站式解决方案,不过我们的解决方案使用java并且强烈依赖强大的数据库服务器</p>
20 楼
mercyblitz
2010-07-26
<div class="quote_title">libingyang 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p>你都做的什么项目呀,数据库老是移来移去的,你想想,如果中国移动先用了oracle数据库,然后换乘DB2的数据库,那是多么大的工作量啊,上次做个版本的升级还忙了好长一段时间呢。</p>
</div>
<p>互联网项目经常这样。 有些项目建立在遗留的项目上,但是数据库要更替,比如License等原因不够。</p>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p>你都做的什么项目呀,数据库老是移来移去的,你想想,如果中国移动先用了oracle数据库,然后换乘DB2的数据库,那是多么大的工作量啊,上次做个版本的升级还忙了好长一段时间呢。</p>
</div>
<p>互联网项目经常这样。 有些项目建立在遗留的项目上,但是数据库要更替,比如License等原因不够。</p>
19 楼
chris_zley
2010-07-26
效率比较高
但我不是很喜欢,而且如果换数据库就傻了
但我不是很喜欢,而且如果换数据库就傻了
18 楼
ironsabre
2010-07-26
oakeye 写道
beeke 写道
这个做法也很正常。我们就有这样的项目:
它一个银行的核心系统
几千万一台的数据库服务器足够强大
开发人员以前大多熟悉C语言,精通SQL调优,不怎么熟悉OO,并且他们为此项目服务了很多年
项目永远也不用考虑到移植
我参与做过一个海外项目,一般程序员甚至连普通的SQL都不用,哪怕是简单的插入数据,都有专人写存储过程。
另外,比起tuxedo这类老资格的中间件,J2EE远不如吹嘘的稳定和快速。把压力推向数据库,使得系统更加稳定,调优也更加容易
它一个银行的核心系统
几千万一台的数据库服务器足够强大
开发人员以前大多熟悉C语言,精通SQL调优,不怎么熟悉OO,并且他们为此项目服务了很多年
项目永远也不用考虑到移植
我参与做过一个海外项目,一般程序员甚至连普通的SQL都不用,哪怕是简单的插入数据,都有专人写存储过程。
另外,比起tuxedo这类老资格的中间件,J2EE远不如吹嘘的稳定和快速。把压力推向数据库,使得系统更加稳定,调优也更加容易
核心都是这样 不用吵什么java还是c 全是存储过程。。。
保险行业的核心系统的核心计算也都是存储过程。
17 楼
liujun999999
2010-07-26
3000多行的应该是存储过程吧,一个sql还没见过这么长的,有的数据库sql有长度限制了,应该到不了这么长
16 楼
libingyang
2010-07-26
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p>你都做的什么项目呀,数据库老是移来移去的,你想想,如果中国移动先用了oracle数据库,然后换乘DB2的数据库,那是多么大的工作量啊,上次做个版本的升级还忙了好长一段时间呢。</p>
<div class="quote_div">
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
</div>
<p>你都做的什么项目呀,数据库老是移来移去的,你想想,如果中国移动先用了oracle数据库,然后换乘DB2的数据库,那是多么大的工作量啊,上次做个版本的升级还忙了好长一段时间呢。</p>
15 楼
jychenok
2010-07-26
我们是单行数据hql,小数据量sql,大数据量存储过程,赞同小粒度简单sql的观点,就算是oracle也是有bug的,有些复杂用法会不稳定的出现问题...我就遇到过左连接+窗口函数出现bug.多出好几万条数据...
14 楼
IcedCoffee
2010-07-26
java的优点是分布式,如果什么都交给数据库,数据库也会不堪重负...
虽然有的中间件是很搓,但是如果使用分布式设置集群,那么压力就能得到缓解.
数据库也舒服多了...
虽然有的中间件是很搓,但是如果使用分布式设置集群,那么压力就能得到缓解.
数据库也舒服多了...
13 楼
mercyblitz
2010-07-25
<div class="quote_title">坏孩子 写道</div>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
<div class="quote_div">
<div class="quote_title">mercyblitz 写道</div>
<div class="quote_div">
<div class="quote_title">javabrother 写道</div>
<div class="quote_div">
<p> 来到这家公司已经快三月了,有点不是很习惯,就是喜欢在sql中写逻辑,在sql中写逻辑是要少些很多的代码,听同事他看见在3000多行的sql,完全没有oop,听着就晕!我sql比较弱哦。</p>
<p> 不知道前辈们怎么看的。谢谢!</p>
</div>
<p> </p>
<p>关键点还是在需求,如果需要在大规模并发访问数据的情况下,尽量传输和返回数据小,同时保证在数据库那端处理时间要小。对于复杂的SQL, 我的建议是简化SQL,把一次SQL语句拆分为几次来做。好处有:</p>
<p>1.SQL属于解释性的语言,关系型数据库解释时间可能比较长。</p>
<p>2.关系型数据一般地使用文件系统,在并发中,I/O瓶颈容易发生。</p>
<p>3.简短的SQL,更好地预编译和缓存结果(如果数据库支持的话)。</p>
<p>4.粒度更小的SQL,易于理解和维护。同时,提高重用性和扩张性,并且有利于SQL迁移(越短的SQL,越接近于标准)。</p>
<p>5.简短的SQL,有利于发挥编程语言性能和语义,弥补RMDB的不足。</p>
</div>
<p> </p>
<p>1. 用预编译</p>
<p>2. 生产环境一般都很牛逼,而且有专职dba调优</p>
<p>3. 更好的预编译,哪里来的结论?除非碰到数据库的bug;简短的sql能更好的缓存结果,你了解数据库么,读读oracle的文档再来吧</p>
<p>4. 迁移sql?你说的是迁移数据库?从来没有考虑过,除非oracle倒闭了</p>
<p>5. 据我所知,有不少公司正考虑将代码迁移到存储过程中。</p>
</div>
<p>1.预编译一定能够提高性能?</p>
<p>2.不知道是否了解NoSQL和10times内存数据库没有,和DBA没有关系,而且在海量数据中,他们并不能解决关系型数据库内在的问题。</p>
<p>3.解释型语言都有这个问题,越长越复杂的语句时间消费越多。如果不是,请您举反例来。</p>
<p>4.迁移数据是很常见的,比如SQLServer迁移到Oracle,除了SQL脚本,还有应用程序代码,工作量巨大。</p>
<p>5.存储过程有其优点,不过存储过程没有标准化。第一、迁移是一个问题。第二,在开发团队中,不是每一个人都熟悉存储过程,更不要说多种数据库的。第三、对于多变输入参数,在修改后的SQL,需要重新编译,反而牺牲性能,并且影响其他操作。建议您看一下:</p>
<p><a href="http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages" target="_blank">http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages</a></p>
<p> </p>
<p>在鄙人的经验中,没有听过和实践一站式的解决方案。没有什么完美的架构,只有适合和不断改良的架构。架构中,简单才是美。</p>
<p> </p>
<p>如果对某个知识了解,那么请使用实际开发场景。大家可以坐下来,相互探讨和学习。其他的话,我不多说了。</p>
12 楼
wangchangbing
2010-07-25
能解决问题才是王道
相关推荐
困惑度是一种常用的评估语言模型好坏的指标,通常在自然语言处理中使用。该资源提供了详细的Python代码,用于计算LDA语言模型的困惑度,并将其与不同主题数量的模型进行比较。 知识点一:困惑度的定义和计算 困惑...
【物业管理中的四个困惑】 物业管理作为现代城市生活的重要组成部分,它涉及到居民日常生活中的诸多方面,包括设施维护、环境管理、安全防护等。随着社会的发展,物业管理行业逐渐规范化,服务质量不断提升,但也...
《困惑的浪漫》是高志鹏先生的一部经典著作,主要聚焦于WINHEX这款强大的十六进制编辑器的高级专题。这本书不仅深入探讨了WINHEX的基本功能,还涵盖了其在数据恢复、取证分析、硬盘修复等领域的高级应用,为读者提供...
本文将从 Python 在前端开发的实践、开发困惑、前端技术演进、单页面应用模型、前端框架等方面对 Python 在前端开发的技术点进行详细的解读。 一、Python 在前端开发的实践 Python 可以用来开发前端应用,例如使用...
Java开发接口帮助文档是开发者在进行Java编程时的重要参考资料,它包含了JDK中的类库、接口、类与类之间的继承关系...掌握并善用这份文档,能够提高开发效率,减少编程过程中的困惑,从而提升整个项目的质量和可靠性。
中国敏捷软件开发联盟通过采集和总结这些成功案例,旨在推动敏捷在国内企业中的深入理解和实践,同时解决国内企业在向敏捷转型过程中遇到的问题和困惑。通过定期的大会、研讨会、培训以及发布的专业资料,联盟正在...
安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码...
本书力图做到传递经过组织的、可操作的软件开发经验,使软件开发领域的新手在知识(软件开发思想)积累过程中少走弯路,也使软件开发领域的老手可以对照自己的经验把可能的困惑降到最低。有一些有趣例子为那些有价值...
在开发过程中,小图标起着至关重要的作用,它们不仅可以提升应用程序的美观度,还能帮助用户快速识别和理解功能。这些小图标通常是矢量图形,能够适应各种尺寸而不失真,确保在不同设备和分辨率上都能呈现出清晰的...
本文总结了C++开发中的常用技术,并对开发中经常遇到的困惑问题给出了详细解答。涵盖了Visual C++开发工具与调试技巧的整理,包括如何在Release状态下进行调试、Release和Debug的区别、ASSERT和VERIFY的区别、...
HTML5在游戏开发中的应用,不仅推动了网页游戏的发展,也极大地丰富了互联网上的互动体验。HTML5之所以能在游戏开发领域崭露头角,主要得益于其一系列强大的特性,包括Canvas、Audio/Video、WebSockets、WebWorkers...
【刘运新新课程高中数学教学中问题困惑分析与解决建议】 在高中数学新课程的实施过程中,教师和学生都面临着一系列的挑战和困惑。这些困惑主要体现在以下几个方面: 1. **新课程与教材体系的问题**: - **知识...
本手册聚焦于Java开发者在实际开发过程中可能遇到的问题和困惑,对Java编程中常见的规约、异常日志处理、单元测试、安全、数据库使用、工程结构、设计等方面做了细致的规定。 本手册的一个重要特点是其内容的系统性...
这也成就了Nginx这方面的巨作——覆盖了Nginx的安装、配置、模块开发、架构解析和深度应用等各个方面,适合不同层次的读者,并能切实地帮助读者有效地解决Nginx应用中所碰到的困惑与难题。 —— 朱少民 同济大学...
在软件开发过程中,图标起着至关重要的作用。它们不仅能够美化界面,还能够直观地向用户传达各种功能和状态信息。"软件开发常用图标大全"集合了大量的图标资源,旨在为开发者提供一个便捷的一站式解决方案,减少寻找...
### HTML5 在游戏开发中的应用 #### 一、HTML5技术背景及发展历程 HTML5作为第五代超文本标记语言的标准,不仅在网页布局和结构上提供了更多灵活性,更重要的是引入了一系列新的API和技术,使得Web应用的功能更加...
教师在课程资源开发中可能过于追求新颖,导致教材的地位被弱化,情境设置过于形式化,联系实际变得空洞,信息处理过于程式化。 教师角色的转换是一个重要的方面,但在实践中可能出现失衡。过度强调学生的自主性和...