История изменений
Исправление no-such-file, (текущая версия) :
Правда, база под задачу в итоге может оказаться нереляционной, и тогда ORM уходит лесом
В нереляционной базе и вообще в приложении всё равно есть какие-то логические отношения между сущностями. То что база не поддерживает реляционные запросы дело десятое. Более того, как раз претензии к «кривости» ORM часто в том, что запросы-де не оптимальные ибо вместо join оно лепит 100500 селектов по ID. Так, ска, это так специально и задумано, чтобы ORM не использовала реляционные запросы. Отношения между объектами реализуются уже после того как объекты получены в самой логике приложения. Хотите реляционные запросы к данным - делайте через билдер получение отчётов. ORM не для этого.
Где здесь нужно запрашивать все сущности
На странице у меня до 500 сообщений в которых т.ч. есть ники пользователей, аватары. На других форумах может быть ещё карма, лайки и 100500 всяких сущностей.
Если выполнять запрос через JOIN, выдающий имя пользователя и аватар в одной строке с сообщением, то вся обработка произойдет внутри СУБД, с минимальными накладными расходами
Блажен, кто верует, ага. А тебе говорю, что запросить один изменившийся ник по ID всегда будет быстрее чем гонять каждый раз запрос с джойном на 500 записей. Даже без кэша, а из той же базы.
Исходная версия no-such-file, :
Правда, база под задачу в итоге может оказаться нереляционной, и тогда ORM уходит лесом
В нереляционной базе и вообще в приложении всё равно есть какие-то логические отношения между сущностями. То что база не поддерживает реляционные запросы дело десятое. Более того, как раз претензии к «кривости» ORM часто в том, что запросы-де не оптимальные ибо вместо join оно лепит 100500 селектов по ID. Так, ска, это так специально и задумано, чтобы ORM не использовала реляционные запросы. Отношения между объектами реализуются уже после того как объекты получены в самой логике приложения. Хотите реляционные запросы к данным - делайте через билдер получение отчётов. ORM не для этого.
Где здесь нужно запрашивать все сущности
На странице у меня до 500 сообщений в которых т.ч. есть ники пользователей, аватары. На других форумах может быть ещё карма, лайки и 100500 всяких сущностей.
Если выполнять запрос через JOIN, выдающий имя пользователя и аватар в одной строке с сообщением, то вся обработка произойдет внутри СУБД, с минимальными накладными расходами
Блажен, кто верует, ага. А тебе говорю, что запросить один изменившийся ник по ID всегда будет быстрее чем гонять каждый раз запрос с джойном на 500 записей. Даже без кэша, а из той же базы.