开发中的困惑！

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

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

Welcome to the real world. It sucks ~

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

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

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

 

关键点还是在需求，如果需要在大规模并发访问数据的情况下，尽量传输和返回数据小，同时保证在数据库那端处理时间要小。对于复杂的SQL， 我的建议是简化SQL，把一次SQL语句拆分为几次来做。好处有：

1.SQL属于解释性的语言，关系型数据库解释时间可能比较长。

2.关系型数据一般地使用文件系统，在并发中，I/O瓶颈容易发生。

3.简短的SQL，更好地预编译和缓存结果（如果数据库支持的话）。

4.粒度更小的SQL，易于理解和维护。同时，提高重用性和扩张性，并且有利于SQL迁移（越短的SQL，越接近于标准）。

5.简短的SQL，有利于发挥编程语言性能和语义，弥补RMDB的不足。

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

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

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


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

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

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

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

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