84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
如题。团队规模为10人。编程环境为 PHP + Python。个人觉得在大家都会 SQL,并且掌握一些 SQL 技巧时,统一使用 SQL 语句可以在以后性能调优时更直观。不知各位“过来人”有何高见。另外在 Model 里有没有必要把 phpredis 的函数重新封装为 ORM ?感觉 Redis 本身就是为速度存在的,如果再在入口处加一些解析、判断、封装,是不是会有悖于 Redis 的主旨,而且涉及数据交互的 Model 在我们团队里仅由2人负责,编码规范化的问题应该不是问题。
光阴似箭催人老,日月如移越少年。
在项目中,更偏向于直接写SQL,而不是用ORM,对于Python之类的弱类型语言,更甚。 SQL表达能力已经很强,比较简单,易于上手。
程序员学习SQL,好处有:1. SQL语句,可以在命令行(mysql) & 其它图形化工具 执行,一边修改,一边调试。2. 在互联网上,SQL的文档很多,而ORM的文档偏少。有困难时,比较容易找到解答3. SQL更通用,你可能学习了很多ORM,但不明白SQL,你能说自己懂ORM了么?
程序员,熟悉SQL,进而数据库,是对自己的要求。这可能是DBA的事,但也是你进步,增值的方法。
网上有的是AR类,随便搞一个用,不要直接写SQL,要是想调节性能你可以加一层logging专门记录慢查询和方法。 我见过很多人把redis封装成ORM的接口,为了使用方便,包裹一些判断和加载那都太正常了,我们可以按需要给redis的ORM、Cache、Count、Queue分别封装, 这处性能影响不大。最主要是加速开发以及可维护性。
使用SQL的好处是直观一点, 但坏处比好处更多,例如硬编码的维护性低、前端人员水平良莠不齐你不能保证每个人写的SQL都一样,最主要的是编写速度慢,我觉得数据库语句这种东西,前端开发人员甚至不该直接接触。
可以使用一些轻量级的ORM,好处就是:1、开发快,很多细节封装起来了,比如数据库连接的使用和释放2、面向对象的开发方式让代码更易理解和维护3、完全不会限制你做SQL调优,比如类似mybatis这样轻量级的ORM,还是使用SQL访问数据
SQL一个比较大的麻烦就是不限权(或者是限权不细)。一个SQL语句的书写失误,可能毁掉整个系统的所有数据。
因此甚至包括WordPress在内的,几乎所有的框架都不怎么提倡直接把SQL语句硬编码(hard code)在程序中,而是必须封装起来。
不要觉得只有两个人做就不必封装了——缺少规矩,人少也出事儿。
在项目中,更偏向于直接写SQL,而不是用ORM,对于Python之类的弱类型语言,更甚。 SQL表达能力已经很强,比较简单,易于上手。
程序员学习SQL,好处有:
1. SQL语句,可以在命令行(mysql) & 其它图形化工具 执行,一边修改,一边调试。
2. 在互联网上,SQL的文档很多,而ORM的文档偏少。有困难时,比较容易找到解答
3. SQL更通用,你可能学习了很多ORM,但不明白SQL,你能说自己懂ORM了么?
程序员,熟悉SQL,进而数据库,是对自己的要求。这可能是DBA的事,但也是你进步,增值的方法。
网上有的是AR类,随便搞一个用,不要直接写SQL,要是想调节性能你可以加一层logging专门记录慢查询和方法。 我见过很多人把redis封装成ORM的接口,为了使用方便,包裹一些判断和加载那都太正常了,我们可以按需要给redis的ORM、Cache、Count、Queue分别封装, 这处性能影响不大。最主要是加速开发以及可维护性。
使用SQL的好处是直观一点, 但坏处比好处更多,例如硬编码的维护性低、前端人员水平良莠不齐你不能保证每个人写的SQL都一样,最主要的是编写速度慢,我觉得数据库语句这种东西,前端开发人员甚至不该直接接触。
可以使用一些轻量级的ORM,好处就是:
1、开发快,很多细节封装起来了,比如数据库连接的使用和释放
2、面向对象的开发方式让代码更易理解和维护
3、完全不会限制你做SQL调优,比如类似mybatis这样轻量级的ORM,还是使用SQL访问数据
SQL一个比较大的麻烦就是不限权(或者是限权不细)。一个SQL语句的书写失误,可能毁掉整个系统的所有数据。
因此甚至包括WordPress在内的,几乎所有的框架都不怎么提倡直接把SQL语句硬编码(hard code)在程序中,而是必须封装起来。
不要觉得只有两个人做就不必封装了——缺少规矩,人少也出事儿。