- 浏览: 17631 次
- 性别:
- 来自: 深圳
最新评论
-
qq1988627:
一个可以吧tomcat jvm空间设大点,二,如果报表是在服务 ...
老系统比较慢,从那些方面着手! -
javabrother:
<div class="quote_title ...
开发中的困惑! -
mercyblitz:
<div class="quote_t ...
开发中的困惑! -
坏孩子:
<div class="quote_t ...
开发中的困惑! -
aws:
<div class="quote_t ...
开发中的困惑!
来到这家公司已经快三月了,有点不是很习惯,就是喜欢在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语言模型的困惑度并作图
按照文档中说的方法,百分百成功。解决初学者的困惑!!!
的对应关系, 在设计二次开发程序时难免产生一些困惑。 目前已经出版的书籍包括网上公共资源中, 关于 CATIA VBA二次开发比较好的资料很少, 这促使我在自己工作经验的基础上写一本参考性资料, 帮助那些想学习 ...
你是否对数字信号处理感到困惑?DSP开发核心教程将为你解开所有的谜团! 从入门到精通 无论你是DSP新手还是有一定经验的开发者,本教程都将带你从基础知识出发,直达高级应用! 实战为王 不仅有理论知识,更有丰富...
总结C++开发中的常用的技术,并对开发中经常遇到的困惑问题给出了详细解答.
本书力图做到传递经过组织的、可操作的软件开发经验,使软件开发领域的新手在知识(软件开发思想)积累过程中少走弯路,也使软件开发领域的老手可以对照自己的经验把可能的困惑降到最低。有一些有趣例子为那些有价值...
安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码(课程大作业).zip安卓开发基于Java开发的DLNA投屏项目源码...
这也成就了Nginx这方面的巨作——覆盖了Nginx的安装、配置、模块开发、架构解析和深度应用等各个方面,适合不同层次的读者,并能切实地帮助读者有效地解决Nginx应用中所碰到的困惑与难题。 —— 朱少民 同济大学...
然后介绍操作系统架构设计和开发环境与开发工具,尤其开发工具,详细了解开发工具会大大方便后面的开发工作并解决一些困惑,最后介绍了操作系统的初始化、HAL、内存管理、中断管理、设备管理、进程管理、文件系统、...
你对课程开发有哪些困惑? 你在课程开发方面有哪些经验可以分享? 第一章:课程目标确定 第二章:逻辑纲要设定 第三章:内容编纂丰富 第四章:检查审核试讲 ... ... ... 关键词:课程开发PPT下载,企业培训...
这是fortran语言的2个实际开发的资料,资料的帮助在于对于科学人员的辅助,而不是指导之后的困惑
【项目介绍】 基于LibVLC开发的DLNA投屏播放器项目源码.zip基于LibVLC开发的DLNA投屏播放器项目源码.zip基于LibVLC开发的DLNA投屏播放器项目源码.zip...无论您是运行还是二次开发,遇到问题或困惑,欢迎私信交流学习。
你在使用智能手机浏览网页时会感到困惑吗? 你是否想知道智能手机上的Web网页是如何实现的? 如果你存在以上的问题并想解决,那么阅读本书将是你的最佳选择。 HTML5从讨论到实践 现今,HTML5已经成为互联网的热门...
Android软件开发安装图解,当你困惑时,希望可以帮助到你
无论您是运行还是二次开发,遇到问题或困惑,欢迎私信交流学习。 基于Rust和CSS开发的机票售票系统源码+课设报告.zip基于Rust和CSS开发的机票售票系统源码+课设报告.zip基于Rust和CSS开发的机票售票系统源码+课设...
【项目介绍】 Vue开发基于Oblivion传输协议的端到端加密信息链路通讯软件源码.zipVue开发基于Oblivion传输协议的端到端加密信息链路通讯软件源码....无论您是运行还是二次开发,遇到问题或困惑,欢迎私信交流学习。
基于Flutter开发的仿微信飞机大战游戏源码(课设项目).zip基于Flutter开发的仿微信飞机大战游戏源码(课设项目).zip基于Flutter开发的仿微信飞机大战游戏源码(课设项目).zip基于Flutter开发的仿微信飞机大战游戏...
【项目介绍】 基于python开发的股票量化策略代项目源码+数据集.zip基于python开发的股票量化策略代项目源码+数据集.zip基于python开发的股票量化策略...无论您是运行还是二次开发,遇到问题或困惑,欢迎私信交流学习。
作为专业级的程序员来说,或许你可以从中找到另一条安全、快捷的编程思路,从而解决你在诸如方案设计,数据构建,分析实现上的困惑。 目前2.0版本:不带数据库,不带查询功能,不带投影变换功能。 方案内容: ...