消息关闭
    暂无新消息!

很多人都吐槽说很多PHP框架中的ORM是非常影响效率的一个组件,那是否可以把ORM设计成像模版引擎一样有一个解析缓存;比如说一个控制器中调用ORM组件的代码在开发模式下执行之后,在框架的temp目录生成一个该控制器中把ORM操作编译成SQL语句的缓存代码,正式上线,关闭debug模式之后就只执行那个缓存代码,也就是代码里面只剩sql语句,没有那些ORM操作的代码了,这样岂不是就像模版引擎缓存一样解决了性能问题?

我观察过像Laravel,YII这样的知名框架居然都没有这样做啊,为什么呐?


5个回答

︿ 2

1,动态网站的各种sql语句,必须动态生成,市场决定需求。
2,php中的ORM是影响效率,但不是非常大,除非是非常复杂的sql(复杂的sql,应当用原生的写,ORM也拼不出来),或者返回巨量数据(这时候应当启用PDO::MYSQL_ATTR_USE_BUFFERED_QUERY)。
3,Yii2的ORM可以解析并缓存关系型数据的的Schema。

︿ 1

orm的性能带来的影响远远小于项目需求不断变动时造成的开发效率的影响,而且php的性能瓶颈是数据库的I/O开销,程序这块开个opcache就够用了

︿ 1

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 等来提升性能。

︿ 0

需要么,时效性,复杂性你考虑过么, 要缓存多少啊. 直接内存里面不更方便么