前天完成ORM中有个小问题,我忽略了,那就是多对一,按我的立即多对一就是一对多,但在多对多的情况下就不是这样了,因为当你做链接时会发现中间的数据表会无法真正融入整个对象集合,原因就是其中有多对一的关系,而我前天自己在实施时的配置也有点问题,居然导致了错误的方法变成了正确的结果,原因在于那天数据的id正好都是1 2 3 4 5 6所以错误的表连接居然恰好变成了正确的结果,发现这个问题之后我迅速的增加了一种外联模式,终于解决了这个巨大的bug。
现在看来ORM的好处不仅是使用方便,更多的是你会对数据表的设计和范式有一个非常深刻的认识,因为在ORM下是不允许错误的数据库范式设计的,我个人体验下来,在ORM下使用,必须达到第二范式标准,如果想完全使用必须达到第三范式,更高的范式现在来看毫无必要,但在以rails为代表的orm中会出现范式越高效率越高的情况,原因就在于他对表的操作很好的把握了delay这个概念,但传统的sql希望是最简单的方法一次取得数据,所以很多老程序员对于范式均会以越低越好著称,因为在他们的理解数据表越冗余,则sql越好些,则查询效率越高,但带来的负面就是数据的不统一和系统扩展维护的复杂度,因此在这个层面上ORM是有意义的,而且绝对应该得到推荐的。
至于效率,昨天在javaeye上看到一个讨论php orm的文章,大多数人都痛骂了php下的orm实现,其实我现在的方案效率也不高,但我觉得在后台上使用尚能接受,而且在代码上确实非常干净这一点正是我想要的东西,现在对于写程序来说,数据库操作变成了配置这是一种享受,这两天应该是心情很愉悦的两天虽然,其实我设计的表由于是标准三范式查询语句极为复杂,但现在却轻松许多,感谢orm这种概念,相信在机器性能大幅提高之后依靠硬件和使用未来的对象数据库之后,orm一定能得到更多的应用。
现在看来ORM的好处不仅是使用方便,更多的是你会对数据表的设计和范式有一个非常深刻的认识,因为在ORM下是不允许错误的数据库范式设计的,我个人体验下来,在ORM下使用,必须达到第二范式标准,如果想完全使用必须达到第三范式,更高的范式现在来看毫无必要,但在以rails为代表的orm中会出现范式越高效率越高的情况,原因就在于他对表的操作很好的把握了delay这个概念,但传统的sql希望是最简单的方法一次取得数据,所以很多老程序员对于范式均会以越低越好著称,因为在他们的理解数据表越冗余,则sql越好些,则查询效率越高,但带来的负面就是数据的不统一和系统扩展维护的复杂度,因此在这个层面上ORM是有意义的,而且绝对应该得到推荐的。
至于效率,昨天在javaeye上看到一个讨论php orm的文章,大多数人都痛骂了php下的orm实现,其实我现在的方案效率也不高,但我觉得在后台上使用尚能接受,而且在代码上确实非常干净这一点正是我想要的东西,现在对于写程序来说,数据库操作变成了配置这是一种享受,这两天应该是心情很愉悦的两天虽然,其实我设计的表由于是标准三范式查询语句极为复杂,但现在却轻松许多,感谢orm这种概念,相信在机器性能大幅提高之后依靠硬件和使用未来的对象数据库之后,orm一定能得到更多的应用。