素材牛VIP会员
在团队中是否应统一使用 ORM?使用 SQL 语句有什么坏处?
 风***j  分类:SQL代码  人气:1145  回帖:7  发布于6年前 收藏

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

 标签:sqlmysqlpythonphp

讨论这个帖子(7)垃圾回帖将一律封号处理……

Lv7 码师
yu***01 产品经理 6年前#1

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

Lv6 码匠
郑***6 页面重构设计 6年前#2

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

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

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

Lv1 新人
Sm***ty CEO 6年前#3

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

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

Lv6 码匠
sh***ng 交互设计师 6年前#4

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

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

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

Lv2 入门
通***程 PHP开发工程师 6年前#5

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

Lv1 新人
Al***ay 职业无 6年前#6

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

Lv6 码匠
yy***15 页面重构设计 6年前#7

个人觉得

使用orm的好处

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

orm的坏处

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

综上

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

 文明上网,理性发言!   😉 阿里云幸运券,戳我领取