I would like to know whether Redbean ORM can be used for performance oriented scenarios like social networking web apps or no and is it stable even if thousands of data are 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 if tis possible, can you give the pros and cons of orm with respect to pure sql according to your experience and also i will google the topic at same time. – Jaison Justus
Well .. explaining this in 600 characters would be hard.
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.
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).
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. Exponential complexity
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.
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.
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.
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. Performance
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.
ORMs are really bad at working with multiple tables, when you need data based on multiple conditions. Consider the problem:
Database contains 4 tables:
Projects,Presentations,SlidesandBulletpoints.
- Projects have many Presentations
- Presentations have many Slides
- Slides have many Bulletpoitns
And you need to find content from all the
Bulletpointsin theSlidestagged as "important" from 4 latestPresentationsrelated to theProjectswith ids 2, 4 and 8.
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. there are other reasons and side-effects, but they are relatively minor .. cannot remember any other important issues right now.