ORM,即Object-Relational Mapping(对象关系映射),它的作用是在关系型数据库和业务实体对象之间作一个映射,这样,我们在具体的操作业务对象的时候,就不需要再去和复杂的SQL语句打交道,只需简单的操作对象的属性和方法。 无可避免的,自动化意味着映射和关联管理,代价是牺牲性能(早期,这是所有不喜欢ORM人的共同点)。现在的各种ORM框架都在尝试使用各种方法来减轻这块(LazyLoad,Cache),效果还是很显著的。 面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象,但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本. 对于复杂查询,ORM仍然力不从心。虽然可以实现,但是不值的。视图可以解决大部分calculated column,case ,group,having,order by, exists,但是查询条件(a and b and not c and (d or d))。。。。。。
任何优势的背后都隐藏着缺点,这是不可避免的。问题在于,我们是否能容忍缺点,以及解决如Doctrine它有它相关的缓存策略来缓存 query metadata result 等来提升性能。
需要么,时效性,复杂性你考虑过么, 要缓存多少啊. 直接内存里面不更方便么
1,动态网站的各种sql语句,必须动态生成,市场决定需求。
2,php中的ORM是影响效率,但不是非常大,除非是非常复杂的sql(复杂的sql,应当用原生的写,ORM也拼不出来),或者返回巨量数据(这时候应当启用PDO::MYSQL_ATTR_USE_BUFFERED_QUERY)。
3,Yii2的ORM可以解析并缓存关系型数据的的Schema。
orm的性能带来的影响远远小于项目需求不断变动时造成的开发效率的影响,而且php的性能瓶颈是数据库的I/O开销,程序这块开个opcache就够用了
ORM,即Object-Relational Mapping(对象关系映射),它的作用是在关系型数据库和业务实体对象之间作一个映射,这样,我们在具体的操作业务对象的时候,就不需要再去和复杂的SQL语句打交道,只需简单的操作对象的属性和方法。
无可避免的,自动化意味着映射和关联管理,代价是牺牲性能(早期,这是所有不喜欢ORM人的共同点)。现在的各种ORM框架都在尝试使用各种方法来减轻这块(LazyLoad,Cache),效果还是很显著的。
面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象,但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本.
对于复杂查询,ORM仍然力不从心。虽然可以实现,但是不值的。视图可以解决大部分calculated column,case ,group,having,order by, exists,但是查询条件(a and b and not c and (d or d))。。。。。。
任何优势的背后都隐藏着缺点,这是不可避免的。问题在于,我们是否能容忍缺点,以及解决如Doctrine它有它相关的缓存策略来缓存 query metadata result 等来提升性能。
最优雅的程序往往也是最高效的。