有人可以解释一下这句话，最好用初学者的语言吗？

Question

在SQLAlchemy的文档页面上，作者以一种哲学开始，

  

SQL数据库的行为不像对象集合那么大小和   表现开始重要;对象集合的行为不像   表和行越抽象就越重要。

我正试图理解这两句话背后的想法，但却失败了。有人能举例说明这个想法吗？感谢。

Answer 1

使用面向对象语言和SQL数据库创建应用程序时，您同时使用两种截然不同的概念模型来存储信息：

• 关系模型说明如何在表格和行中存储数据以及如何通过键和连接链接元素。
• 对象模型建立了一种方法，用于在内存中存储具有属性的实体（通常），以及如何使用指针或引用在它们之间设置链接。

因此，我们假设您有一个用户实体链接到应用程序中的地址和其他用户。这些实体将需要以数据库中的几个表的形式存储（例如，用户表，地址表和用于将用户与用户相关联的多对多表）。同时，如果您的代码使用面向对象的构造，则用户和地址将以对象的形式存在于内存中，并在它们之间引用，指向相同或不同类型的对象。

问题是，在这两个不同的世界之间移动信息要比最初看起来困难得多：

• 您可以将一个对象与表中的一行相关联，但这并不总是可行的，有时单个对象必须与不同表中的多个行相关联。
• 继承和多态行为特别难以映射到关系模型。
• 遍历对象和查询数据库的行为截然不同。
• 在对象模型和关系模型中要考虑的性能因素完全不同。

这些仅仅是几个例子。诸如SQLAlchemy之类的ORM本质上是翻译器，它将信息从一个世界转换为另一个世界并返回。

我认为 Mike Bayer 试图传达的是：您将实体信息更多地适应对象模型（大量继承，多态，对象遍历......），它将更接近关系模型中的自然结构，并且您将获得更多的性能让步。反之亦然：您设计表格越多，表现越好并针对您的查询进行优化，它们就越不适应自然的对象结构。

Martin Fowler在本文中有一篇关于此翻译需求的精彩文章：ORM Hate（我从中获取了上述图片）。

编辑：进一步澄清抽象与效果问题

最后，我认为SQLAlchemy演示文稿的底线是：许多ORM隐藏了面向关系对象的翻译的关系方面，使事情变得更容易。有了它们，你只需要担心面向对象的一面，而且库负责带走处理数据库的负担。无需处理SQL就可以获得对象的持久性。但是，这样做会导致性能下降，因为使用数据库的细节会被抽象掉，而您无法控制它们。当您必须优化性能时，这些细节是必需。 SQLAlchemy采用相反的方法。它隐藏了关系方面的缺点，您可以控制SQL的生成方式以及何时以及何时不使用连接，子查询和其他SQL结构。这使得它成为一个更复杂的学习库，但与此同时，您可以控制整个关系对象导向的翻译过程。