RedBean对象关系映射性能

Question

我想知道，Redbean ORM是否可以用于社交网络web应用等面向性能的场景，即使多个用户同时拉取数千个数据，它也是稳定的吗？另外，我想知道Redbean是否会消耗更多的内存空间？

有人能提供一个Doctrine-Propel-Redbean的比较研究吗？

Answer 1

@tereško如果可能的话，你能根据你的经验给出orm关于纯sql的优缺点吗?我也会同时谷歌这个话题。- Jaison Justus

好吧..。用600个字符来解释这一点是很困难的。

有一件事我必须澄清:这是关于PHP中的Ruby，尽管我非常确定它也适用于一些ORM，也许也适用于其他。

简而言之，你应该避免它们，但如果你必须使用ORM，那么你会更好地使用Doctrine 2.x，它是较小的邪恶。(实现类似于DataMapper的东西，而不是ActiveRecord)。

针对ORM的案例

一些开发人员喜欢使用ORM的主要原因也是它们最糟糕的地方：在ORM中很容易做简单的事情，但性能代价很小。这是非常好的。

1.指数复杂度

问题的根源在于人们使用相同的工具来做任何事情。如果你只有一个锤子(..)问题的类型。这将导致创建一个technical debt。

首先，编写新的与数据库相关的代码很容易。也许，因为你有一个大项目，管理层在最初几周(因为以后会遇到额外的问题-如果对细节感兴趣，请阅读 )决定雇佣更多的人。你最终会更喜欢有ORM技能的人，而不是一般的SQL。

但是，随着项目的进展，您将开始使用ORM来解决日益复杂的问题。你会开始绕过一些限制，最终你可能会遇到一些问题，即使你知道所有的ORM黑客也不能解决这些问题……现在你没有SQL专家，因为你没有雇佣他们。

此外，大多数流行的ORM都实现了ActiveRecord，这意味着您的应用程序的业务逻辑直接耦合到ORM。由于这种耦合，添加新功能将需要越来越多的时间。出于同样的原因，为它们编写好的单元测试是极其困难的。

2. Performance

我已经提到过，即使是简单地使用ORM (使用单表，没有JOIN)也会有一些性能成本。这是因为他们使用通配符*来选择数据。当您只需要文章ID和标题的列表时，获取内容就没有意义了。

当您需要基于多个条件的数据时，ORM在处理多个表方面真的很糟糕。考虑一下这个问题：

数据库包含4个表：Projects、Presentations、Slides和Bulletpoints。

• 项目具有多个Presentations
• Presentations，多个Slides
• Slides，多个Bulletpoitns

您需要从Slides中标记为“重要”的所有Bulletpoints中查找与ids为2、4和8的Presentations相关的4个最新Projects中的内容。

这是一个用纯SQL编写的简单连接，但在我所见过的任何ORM实现中，这将导致三层嵌套循环，在每一层上都有查询。

P.S.还有其他原因和副作用，但它们相对较小。现在记不起任何其他重要的问题了。

Answer 2

我觉得Tereško的答案不太正确。

首先，它没有解决最初的问题。这确实是一个针对ORMs的案例，我同意他的回答中描述的问题。这就是我写RedBeanPHP的原因。仅仅因为大多数ORM不能使您的生活更轻松，并不意味着对象关系映射系统的概念是有缺陷的。大多数ORM都试图隐藏SQL，这就是连接变得如此复杂的原因；它们需要在面向对象的环境中重新发明类似的东西。这就是RedBeanPHP的不同之处，因为它没有隐藏SQL。它创建可读的、有效的、易于查询的SQL表。RedBeanPHP没有使用虚构的查询语言，而是使用普通的旧式SQL进行记录和bean检索。简而言之，RedBeanPHP与SQL协同工作，而不是与SQL对抗。这使得它变得简单得多。

是的，RedBeanPHP的性能很好。我怎么能这么确定呢？因为与其他ORM不同，RedBeanPHP区分开发模式和生产模式。在开发周期中，数据库是流动的；您可以添加条目，它们将被动态添加。RedBeanPHP创建列，索引，猜测数据类型等。如果你需要更多的字节(更高的数据类型)，它甚至可以伸展列。这使得RedBeanPHP非常慢，但只有在开发时，速度不应该是问题。一旦您完成了开发，您就可以使用带有单一模式说明符R:: freeze ()的freeze the database，并且不再执行任何检查。在生产服务器上，剩下的是一个非常简单的数据库层。因为没有做太多的事情，所以性能很好。

是的，我知道，我是RedBeanPHP的作者，所以我有偏见。然而，我觉得我的ORM和其他ORM一样被看待，这促使我写下这篇文章。如果您想了解更多，请随时查阅RedBeanPHP website，这里有一个discussion on performance。

在我们公司，我们将RedBeanPHP用于嵌入式系统以及金融业务系统，因此它似乎具有很好的扩展性。

我和ORM社区一起，诚心诚意地努力让RedBeanPHP世界变得更美好；您可以阅读使命声明here。

祝你的项目好运，我希望你能找到你正在寻找的技术解决方案。

Answer 3

我在这里与@tereško不同-ORM可以使数据库查询更容易编写和维护。在我看来，在Propel和Doctrine中有一些很棒的工作--利用它们！网上有许多性能比较，也可以查看NotORM (我还没有用过它，但如果我没记错的话，他们做了一些与Doctrine的比较)。

如果您的吞吐量需要执行原始SQL，则在该点进行优化。但在减少bug数量和提高生产率方面，我认为您节省的资金无论如何都会为更好的服务器提供资金。当然，您的里程可能会有所不同。

顺便说一句，我不知道RedBean，但我认为Propel在大多数情况下比Doctrine更快，因为类是预先生成的。当Propel是唯一的选择时，我使用了Propel，并坚持使用它，尽管我当然不反对使用Doctrine。

2018年更新

Propel 2在几年后仍处于alpha阶段，并需要许多大型重构项目，但遗憾的是，这些项目并未完成。尽管维护者说这个alpha在生产中很好用，因为它有很好的测试覆盖率，他们现在已经开始使用Propel 3了。不幸的是，在我写这篇文章的时候，它实际上还没有任何发布，尽管这个存储库已经有一年的历史了。

虽然我认为Propel是一个伟大的项目，但我想知道目前使用其他东西是不是最好。它仍有可能从灰堆中复活！