开发中的困惑！

 来到这家公司已经快三月了，有点不是很习惯，就是喜欢在sql中写逻辑，在sql中写逻辑是要少些很多的代码，听同事他看见在3000多行的sql，完全没有oop，听着就晕！我sql比较弱哦。

  不知道前辈们怎么看的。谢谢！

评论

11 楼 坏孩子 2010-07-25  

<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>

10 楼 glamey 2010-07-25  

现在在公司里边如果存储过程写的牛逼的话，那薪水是大大的啊

9 楼 javabrother 2010-07-25  

firehoo 写道

那位写3000多行sql的兄弟如果跳槽了，让一个新来的改他的这段代码，那个新来的会不会觉得郁闷？

这个sql是台湾的一个同事写的， 它们写的sql 先把sql语法和关键字写出来，在填条件。这个方法我受教了，以前自己写的sql是 从左到右的写，现在看起来很傻，花的时间review比较多。现在的这种写法虽然看起来很傻，但是写出来的东西很规范的，一看就懂，sql关键字做一行，查询的每个字段做一行，每个条件做一行。往往不会出错！

8 楼 oakeye 2010-07-25  

beeke 写道

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

它一个银行的核心系统
几千万一台的数据库服务器足够强大
开发人员以前大多熟悉C语言，精通SQL调优，不怎么熟悉OO，并且他们为此项目服务了很多年
项目永远也不用考虑到移植


我参与做过一个海外项目，一般程序员甚至连普通的SQL都不用，哪怕是简单的插入数据，都有专人写存储过程。

另外，比起tuxedo这类老资格的中间件，J2EE远不如吹嘘的稳定和快速。把压力推向数据库，使得系统更加稳定，调优也更加容易

核心都是这样  不用吵什么java还是c  全是存储过程。。。

7 楼 redK 2010-07-25  

firehoo 写道

那位写3000多行sql的兄弟如果跳槽了，让一个新来的改他的这段代码，那个新来的会不会觉得郁闷？

花得几天慢慢看，还是能看出点冬瓜豆腐来的。。。。

6 楼 beeke 2010-07-25  

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

它一个银行的核心系统
几千万一台的数据库服务器足够强大
开发人员以前大多熟悉C语言，精通SQL调优，不怎么熟悉OO，并且他们为此项目服务了很多年
项目永远也不用考虑到移植


我参与做过一个海外项目，一般程序员甚至连普通的SQL都不用，哪怕是简单的插入数据，都有专人写存储过程。

另外，比起tuxedo这类老资格的中间件，J2EE远不如吹嘘的稳定和快速。把压力推向数据库，使得系统更加稳定，调优也更加容易

5 楼 firehoo 2010-07-25  

那位写3000多行sql的兄弟如果跳槽了，让一个新来的改他的这段代码，那个新来的会不会觉得郁闷？

4 楼 mercyblitz 2010-07-24  

<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>

3 楼 beneo 2010-07-24  

我不知道这种做法是不是主流，但是听起来很有意思。。

在网上面封装说不定就是一个hibernate了。。

2 楼 Kisses99 2010-07-24  

这没什么不好啊，如果sql优化的好，效率各方面都很好啊。
OOP又不是宝典，必须要遵守的，一切面向应用。

1 楼 jerryfeng 2010-07-23  

Welcome to the real world. It sucks ~