开发中的困惑！

 来到这家公司已经快三月了，有点不是很习惯，就是喜欢在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，不是存储过程。

这位哥哥正解，持久层用的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>

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>

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>

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>

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>

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>

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>

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>

19 楼 chris_zley 2010-07-26  

效率比较高

但我不是很喜欢，而且如果换数据库就傻了

18 楼 ironsabre 2010-07-26  

oakeye 写道

beeke 写道

这个做法也很正常。我们就有这样的项目：

它一个银行的核心系统
几千万一台的数据库服务器足够强大
开发人员以前大多熟悉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>

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>

12 楼 wangchangbing 2010-07-25  

能解决问题才是王道