84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
如题。团队规模为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)在程序中,而是必须封装起来。
不要觉得只有两个人做就不必封装了——缺少规矩,人少也出事儿。