开发中的困惑！

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

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

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

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

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

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

1. 用预编译

2. 生产环境一般都很牛逼，而且有专职dba调优

3. 更好的预编译，哪里来的结论？除非碰到数据库的bug；简短的sql能更好的缓存结果，你了解数据库么，读读oracle的文档再来吧

4. 迁移sql？你说的是迁移数据库？从来没有考虑过，除非oracle倒闭了

5. 据我所知，有不少公司正考虑将代码迁移到存储过程中。

1.预编译一定能够提高性能？

2.不知道是否了解NoSQL和10times内存数据库没有，和DBA没有关系，而且在海量数据中，他们并不能解决关系型数据库内在的问题。

3.解释型语言都有这个问题，越长越复杂的语句时间消费越多。如果不是，请您举反例来。

4.迁移数据是很常见的，比如SQLServer迁移到Oracle，除了SQL脚本，还有应用程序代码，工作量巨大。

5.存储过程有其优点，不过存储过程没有标准化。第一、迁移是一个问题。第二，在开发团队中，不是每一个人都熟悉存储过程，更不要说多种数据库的。第三、对于多变输入参数，在修改后的SQL，需要重新编译，反而牺牲性能，并且影响其他操作。建议您看一下：

http://en.wikipedia.org/wiki/Stored_procedure#Disadvantages

在鄙人的经验中，没有听过和实践一站式的解决方案。没有什么完美的架构，只有适合和不断改良的架构。架构中，简单才是美。

如果对某个知识了解，那么请使用实际开发场景。大家可以坐下来，相互探讨和学习。其他的话，我不多说了。