开发中的困惑！

 

你真的以为动态sql会导致存储过程重新编译？如果不是，请问java执行sql不需要重新解析sql？你的话我看不懂了

 

<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，不是存储过程。