Реализация ORM обычно такова, что это тот же SQL синтаксис только в виде объекта вызовов методов объектов.
- В простых случаях, что то типа: User::findAll()->where(['id'=>10])
Это как бы прикольно, но тот же SQL: SELECT * FROM user WHERE id =10 не выглядит более сложным.
- Join, ORM как бы скрывает джойны:
$UserCollection = User::findAll()->where(['id'=>10]);
foreach($UserCollection as $User){
if($User->ProfileSetting->is_enable == 'yes'){
doSomething($User);
}
}
Тут как бы скрыто то, что запрос происходит к двум связанным таблицам (user и profile), это достаточно в многих случаях, но в любом случае это не круто, т.к. вы не знаете какой запрос или запросы генерит ORM и не понимаете, что происходит на самом деле.
- Внешний вид запросов в объектном представлении становиться тяжёлым для восприятия даже для запросов средней сложности, с SQL таких проблем нет.
- Для сложных запросов ORM не даёт ни чего, кроме варианта писать тот же SQL.
ORM имеет серьёзные преимущества в кодогенерации, в написании автоматизированных тестов.
Если у вас есть какие то планы стать не начинающем разработчиком, то вам неприменимо нужно начать разбираться как работают базы данных в целом, т.е. понимание реляционной алгебры (это по сути и есть SQL), и понимание того, что стоят запросы (насколько нагружают диск/процессор).
Так происходит потому, что по мере роста вашей квалификации у вас будут пропадать сопутствующие задачи типа вёрстки и js, готовую архитектуру вам навяжут фреймворки, а вашей основной задачей будет манипуляции с небольшими блоками данных хранящимися в больших массивы данных.
Средний
