ORM从哪里掉下来?

对于我使用的所有窗体,我注意到的一个更大的问题是在不首先检索对象的情况下只更新几个字段。

例如,假设我在数据库中映射了一个项目对象,其中包含以下字段:ID、名称、描述、拥有用户。比如,通过Ajax,我只想更新描述字段。在大多数ORM中,在只有ID和描述值的情况下更新数据库表的唯一方法是从数据库中检索项目对象,设置描述,然后将对象发送回数据库(因此只需要两个数据库操作进行一次简单的更新),或者通过存储过程(即我目前使用的方法)。

对象和数据库记录并不完全相似。他们打了一些插槽,你可以把东西放进去,但这就是问题所在。与编程语言相比,数据库具有完全不同的标识概念。它们不能很好地处理复合对象,因此必须使用其他表和外键。大多数没有类型继承的概念。当映射到数据库世界时,导航对象网络的自然方法(遵循一个对象中的一些指针,获取另一个对象,然后再次取消引用)效率要低得多,因为您必须进行多次往返,并检索许多您不关心的数据。

换句话说:抽象一开始不能做得很好;不好的不是ORM工具,而是它们实现的隐喻。它不是一个完美的同构,而是一个表面上的相似性,因此任务本身不是一个很好的抽象。(尽管如此,它仍然比密切了解数据库更有用。对ORM工具的蔑视主要来自DBA对程序员的鄙视。)

ORM还可以编写效率不高的代码。由于数据库性能对大多数系统都至关重要,因此它们可能会导致一些问题,如果编写代码的人能够避免这些问题(但是,如果有问题的人不了解数据库性能调优的话,情况可能不会更好)。当查询变得复杂时尤其如此。

不过,我认为他们最大的问题是,通过抽象出细节,初级程序员对如何编写查询的了解越来越少,而这些查询需要他们能够处理边缘情况,以及ORM编写非常糟糕的代码的地方。当你不必了解基础知识的时候,学习先进的东西真的很难。掌握连接、分组和高级查询的ORM是一件好事。在不了解布尔代数和联接以及其他一些基本SQL概念的人手中,这是一件非常糟糕的事情,导致数据库和查询的设计非常糟糕。

关系数据库不是对象,不应这样对待。试图把一只鹰变成一个丝绸钱包通常是不成功的。要知道老鹰擅长什么,为什么,让老鹰飞远比拥有一个坏钱包和一只死鹰要好得多。

我看是这样的。要使用ORM,通常需要堆叠几个PHP函数,然后连接到数据库,基本上仍然要运行MySQL查询或类似的操作。

为什么在代码和数据库之间进行所有的抽象?为什么我们不能用我们已经知道的?通常,Web开发人员知道他们的后端语言、数据库语言(某种SQL)和一些前端语言,如HTML、CSS、JS等…

本质上,我们试图添加一个包含许多函数的抽象层(我们都知道PHP函数比分配变量要慢)。是的,这是一个微观计算,但总的来说。

不仅我们现在有几个功能要完成,而且我们还必须学习ORM的工作方式,因此这里浪费了一些时间。我认为代码分离的整个想法是在所有级别上保持代码分离。如果您身处LAMP世界,只需创建查询(您应该了解MySQL),并为准备好的语句使用已经存在的PHP功能。完成!

灯道:

• 创建查询(字符串);
• 使用mysqli准备好的语句并将数据检索到数组中。

奥姆路:

• 运行获取实体的函数
• 它运行一个mysql查询
• 运行另一个添加条件的函数
• 运行另一个添加另一个条件的函数
• 运行连接的另一个函数
• 运行另一个在联接上添加条件的函数
• 运行另一个函数来准备
• 运行另一个MySQL查询
• 运行另一个获取数据的函数
• 运行另一个MySQL查询

其他人对ORM堆栈有问题吗?为什么我们会成为如此懒惰的开发人员?或者是我们在破坏我们的代码?如果还没坏,就别修了。反过来,修复您的开发团队以了解Web开发的基础知识。

ORM正试图解决一个非常复杂的问题。有大量的边缘案例和主要的设计权衡,没有明确或明显的解决方案。当您为情况A优化ORM设计时,本质上会使解决情况B变得困难。

有些窗体以“足够好”的方式处理延迟加载和子查询,但几乎不可能从“足够好”到“非常好”。

在设计您的ORM时,您必须对您的ORM将要处理的所有可能笨拙的数据库设计有一个很好的处理。你必须明确权衡哪些情况下你愿意处理尴尬。

我不认为窗体是不灵活的,或者比您的一般复杂抽象更容易泄漏。也就是说,某些形式在这些方面比其他形式更好。

祝你好运,重新发明轮子。