在团队中是否应统一使用 ORM？使用 SQL 语句有什么坏处？

如题。
团队规模为10人。编程环境为 PHP + Python。
个人觉得在大家都会 SQL，并且掌握一些 SQL 技巧时，统一使用 SQL 语句可以在以后性能调优时更直观。不知各位“过来人”有何高见。
另外在 Model 里有没有必要把 phpredis 的函数重新封装为 ORM ？感觉 Redis 本身就是为速度存在的，如果再在入口处加一些解析、判断、封装，是不是会有悖于 Redis 的主旨，而且涉及数据交互的 Model 在我们团队里仅由2人负责，编码规范化的问题应该不是问题。

回复内容：

如题。
团队规模为10人。编程环境为 PHP + Python。
个人觉得在大家都会 SQL，并且掌握一些 SQL 技巧时，统一使用 SQL 语句可以在以后性能调优时更直观。不知各位“过来人”有何高见。
另外在 Model 里有没有必要把 phpredis 的函数重新封装为 ORM ？感觉 Redis 本身就是为速度存在的，如果再在入口处加一些解析、判断、封装，是不是会有悖于 Redis 的主旨，而且涉及数据交互的 Model 在我们团队里仅由2人负责，编码规范化的问题应该不是问题。

SQL一个比较大的麻烦就是不限权（或者是限权不细）。一个SQL语句的书写失误，可能毁掉整个系统的所有数据。

因此甚至包括WordPress在内的，几乎所有的框架都不怎么提倡直接把SQL语句硬编码（hard code）在程序中，而是必须封装起来。

不要觉得只有两个人做就不必封装了——缺少规矩，人少也出事儿。

可以使用一些轻量级的ORM，好处就是：
1、开发快，很多细节封装起来了，比如数据库连接的使用和释放
2、面向对象的开发方式让代码更易理解和维护
3、完全不会限制你做SQL调优，比如类似mybatis这样轻量级的ORM，还是使用SQL访问数据

网上有的是AR类，随便搞一个用，不要直接写SQL，要是想调节性能你可以加一层logging专门记录慢查询和方法。
我见过很多人把redis封装成ORM的接口，为了使用方便，包裹一些判断和加载那都太正常了，我们可以按需要给redis的ORM、Cache、Count、Queue分别封装， 这处性能影响不大。最主要是加速开发以及可维护性。

使用SQL的好处是直观一点， 但坏处比好处更多，例如硬编码的维护性低、前端人员水平良莠不齐你不能保证每个人写的SQL都一样，最主要的是编写速度慢，我觉得数据库语句这种东西，前端开发人员甚至不该直接接触。

在项目中，更偏向于直接写SQL，而不是用ORM，对于Python之类的弱类型语言，更甚。 SQL表达能力已经很强，比较简单，易于上手。

程序员学习SQL，好处有：
1. SQL语句，可以在命令行(mysql) & 其它图形化工具 执行，一边修改，一边调试。
2. 在互联网上，SQL的文档很多，而ORM的文档偏少。有困难时，比较容易找到解答
3. SQL更通用，你可能学习了很多ORM，但不明白SQL，你能说自己懂ORM了么？

程序员，熟悉SQL，进而数据库，是对自己的要求。这可能是DBA的事，但也是你进步，增值的方法。

可以参考discuz的封装，另外对所有涉及到sql的更改都进行2人左右的review

http://www.cnblogs.com/needrunning/archive/2011/11/15/2250068.html

个人觉得

使用orm的好处

<code>1. 节约时间，指的是程序员的时间，如果题主不是做效率要求很高的东西，整个团队节约下来的时间是很客观的，非常喜欢一句话“宁花机器一分，不花程序员一秒”，题主选择了python，相信应个对这个体会比较深吧(生命苦短，我用python～)
2. 适合工程，对同一类需求，基本上不同人写出来的东西是一样的，sql有这种问题，如果一个人写了很复杂的东西，这个成员离职或怎样，这段代码就会变成野草(非常难看懂，非常痛苦)，早晚会被之后的维护者重写的，orm的话代码逻辑比较清晰。
</code>

orm的坏处

<code>1. 效率，orm的话会存在一些效率的问题，毕竟编译的时候会生成一些别的代码，可能一个复杂的需求写4、5十行sql的效率 > orm的效率，不过实在是很蛋疼
2. 学习成本，很多人都是先学sql，然后接触orm，自然有学习成本的问题，而且使用orm就要符合orm的规范，有些高效的orm使用方式还是一种隐藏的附加技能，需要不断探索
</code>

综上

对于一个把程序员的时间看作第一位的团队(项目超期是很正常的事情)，如果对程序的执行效率要求不是超高的话，是用orm绝对是让你轻松的一件事情。