RedBean ORM 性能
我想知道，Redbean ORM能不能用在社交网络应用这种面向性能的场景中，多用户同时拉取上千条数据是否稳定?另外我想知道Redbean是否消耗更多的内存空间?
I would like to know, can Redbean ORM be used for performance oriented scenarios like social networking web apps, and is it stable even if thousands of data is pulled by multiple users at same time? Also I'd like to know whether Redbean consumes more memory space?
谁能提供教义-推进-红豆的比较研究?
Can anyone offer a comparison study of Doctrine-Propel-Redbean?
推荐答案
@tereško 如果可能的话，您能否根据您的经验给出 orm 相对于纯 sql 的优缺点，我也会同时搜索该主题.– 杰森·贾斯图斯
嗯 .. 用 600 个字符来解释这一点很难.
Well .. explaining this in 600 characters would be hard.
我必须澄清一件事:这是关于 PHP 中的 ORM，尽管我很确定它也适用于某些 Ruby ORM，也许还有其他.
One thing I must clarify: this is about ORMs in PHP, though i am pretty sure it applies to some Ruby ORMs too and maybe others.
简而言之，你应该避免它们，但如果你必须使用 ORM，那么你会更好地使用 Doctrine 2.x ，这是较小的邪恶.(实现类似于 DataMapper 而不是 ActiveRecord).
In brief, you should avoid them, but if you have to use an ORM, then you will be better of with Doctrine 2.x , it's the lesser evil. (Implements something similar to DataMapper instead of ActiveRecord).
一些开发人员喜欢使用 ORM 的主要原因也是他们最糟糕的地方:在 ORM 中很容易做简单的事情，性能成本非常低.这完全没问题.
The main reason why some developers like to use ORMs is also the worst thing about them: it is easy to do simple thing in ORM, with very minor performance costs. This is perfectly fine.
1.指数复杂度
问题源于人们对所有事物都使用相同的工具.如果你只有锤子 (..) 类型的问题.这会导致产生技术债务.
The problem originates in people to same tool for everything. If all you have is a hammer (..) type of issue. This results in creating a technical debt.
起初编写新的数据库相关代码很容易.也许，因为你有一个大项目，在第一周进行管理(因为稍后会出现其他问题 - 阅读 神话般的人月，如果对细节感兴趣) 决定雇用更多人.与一般 SQL 相比，您最终会更喜欢具有 ORM 技能的人.
At first it is easy to write new DB related code. And maybe, because you have a large project, management in first weeks (because later it would case additional issues - read The Mythical Man-Month, if interested in details) decides to hire more people. And you end up preferring people with ORM skills over general SQL.
但是，随着项目的进展，您将开始使用 ORM 来解决日益复杂的问题.您将开始绕过一些限制，最终您可能会遇到即使使用您知道的所有 ORM hack 也无法解决的问题......现在您没有 SQL 专家，因为您没有雇用他们.
But, as project progresses, you will begin to use ORM for solving increasingly complex problems. You will start to hack around some limitations and eventually you may end up with problems which just cannot be solved even with all the ORM hacks you know ... and now you do not have the SQL experts, because you did not hire them.
此外，大多数流行的 ORM 都在实现 ActiveRecord，这意味着您的应用程序的业务逻辑是直接耦合到ORM.由于这种耦合，添加新功能将花费越来越多的时间.出于同样的原因，为它们编写好的单元测试非常困难.
Additionally most of popular ORMs are implementing ActiveRecord, which means that your application's business logic is directly coupled to ORM. And adding new features will take more and more time because of that coupling. And for the same reason, it is extremely hard to write good unit-tests for them.
<强>2.性能
我已经提到，即使是简单的 ORM 使用(使用单个表，没有 JOIN)也会有一些性能成本.这是因为他们使用通配符 * 来选择数据.当您只需要文章 ID 和标题列表时，获取内容是没有意义的.
I already mentioned that even simple uses of ORM (working with single table, no JOIN) have some performance costs. It is due to the fact that they use wildcard * for selecting data. When you need just the list of article IDs and titles, there is no point on fetching the content.
当您需要基于多个条件的数据时，ORM 非常不适合处理多个表.考虑问题:
ORMs are really bad at working with multiple tables, when you need data based on multiple conditions. Consider the problem:
数据库包含 4 个表:Projects、Presentations、Slides 和 Bulletpoints.
Database contains 4 tables:
Projects,Presentations,SlidesandBulletpoints.
- 项目有很多演示文稿
- 演示文稿有很多幻灯片
- 幻灯片有很多要点
并且您需要从与 <代码>项目 ID 为 2、4 和 8.
And you need to find content from all the Bulletpoints in the Slides tagged as "important" from 4 latest Presentations related to the Projects with ids 2, 4 and 8.
这是一个用纯 SQL 编写的简单 JOIN，但在我见过的任何 ORM 实现中，这将导致 3 级嵌套循环，每个级别都有查询.
This is a simple JOIN to write in pure SQL, but in any ORM implementation, that i have seen, this will result in 3-level nested loop, with queries at every level.
P.S.还有其他原因和副作用，但它们相对较小..暂时不记得任何其他重要问题.
P.S. there are other reasons and side-effects, but they are relatively minor .. cannot remember any other important issues right now.
相关文章