I would go with "Horses for Courses" situation that utilizes a mix and match of both the worlds. I have built few large scale applications using RedBean, so my comment will focus purely on RedBean and not on other ORMs.
IS RedBean ORM SLOW?
Well, it depends on how you use it. In certain scenarios, it's faster than traditional query because RedBean cache the result for few seconds. Reusing the query will produce result faster. Have a look at the log using R::debug(true); It always shows
"SELECT * FROM `table` -- keep-cache"
Scenario 1: Fetching All (*)
In RedBean if you query
$result = R::findOne('table', ' id = ?', array($id));
This is represented as
$result= mysql_query("Select * from TABLE where id =".$id);
You may argue that if the table is having multiple columns why should you query (*).
Scenario 2: Single column
Fetching a single column
R::getCol( 'SELECT first_name FROM accounts' );
Like i mentioned "Horses for Courses", developers should not simply rely on FindOne, FindAll, FindFirst, FindLast but also carefully draft what they really need.
Scenario 3: Caching
When you don't need caching, you can disable at application level which isn't an ideal situation
R::$writer->setUseCache(true);
RedBean suggests that if you don't want to disable caching at the application level you should use traditional query with no-cache parameter like $result = R::exec("SELECT SQL_NO_CACHE * FROM TABLE");
This perfectly solves the problem of fetching real-time data from table by completely discarding query cache.
Scenario 4: Rapid Development
Using ORM makes your application development really fast, developers can code using ORM 2-3x faster than writing SQL.
Scenario 5: Complex Queries & Relationships
RedBean presents a really nice way of implementing complex queries and one-to-many or many-to-many relationships
Plain SQL for complex queries
$books = R::getAll( 'SELECT
book.title AS title,
author.name AS author,
GROUP_CONCAT(category.name) AS categories FROM book
JOIN author ON author.id = book.author_id
LEFT JOIN book_category ON book_category.book_id = book.id
LEFT JOIN category ON book_category.category_id = category.id
GROUP BY book.id
' );
foreach( $books as $book ) {
echo $book['title'];
echo $book['author'];
echo $book['categories'];
}
OR RedBean way of handling many-t-to-many relationships
list($vase, $lamp) = R::dispense('product', 2);
$tag = R::dispense( 'tag' );
$tag->name = 'Art Deco';
//creates product_tag table!
$vase->sharedTagList[] = $tag;
$lamp->sharedTagList[] = $tag;
R::storeAll( [$vase, $lamp] );
Performance Issues
The arguments like ORMs are typically slow, consumes more memory and tends to make an application slow. I think they are not talking about RedBean.
We have tested it with MySQL and Postgres both, trust me performance was never a bottleneck.
There is no denying that ORMs adds up little overhead and tend to make your application slower ( just a little ). Using ORM is primarily a trade-off between developer time and slightly slower runtime performance. My strategy is to first build the application end-to-end with the ORM then based on test cases, tweak the speed critical modules to use straight data access.
