Сделайте свое приложение масштабируемым, оптимизировав производительность ORM

[pbatanov]

и еще N запросов, чтобы получить автора каждой статьи и вывести значение поля «имя» (name), даже если автор всегда один и тот же.

что говорит о том, что перед нами плохо спроектированная ORM. доктрина например сделает только 1 доп. запрос если у всех статей один автор, а все остальные пойдут через identity cache. не может быть такого в системе с ORM, что в памяти находятся два различных объекта отражающих одну и ту же entity, это сразу выстрел себе в ногу, в частности как раз во всяких отношениях, т.к. корректно траверсить графы объектов становится невозможнным.

Это конечно все не отменяет основной тезис о том, что в циклах с ленивой загрузкой надо быть аккуратным

SELECT * FROM articles;

SELECT * FROM authors WHERE id IN (1, 2, 3, 4, ...);

Опять же, доктрина вместо двух запросов при EAGER загрузке сгенерирует вообще один запрос с джоином, а не два. Особенно весело, полагаю, будет выглядеть такая пара запросов если в таблице тысячи записей

[65536]

Я еще такое прописал в классе, от которого все модели экстендятся

public static function getBuilder()
{
    return \DB::table((new static)->getTable());
}

В случаях когда не нужны связи и функциональность моделей, лучше кверибилдером пользоваться, элоквентовское оборачивание записей в модели занимает очень много времени и памяти на больших выборках. Сделал так чтобы в коде имена таблицы не дублировать при создании кверибилдера каждый раз

[LeMaX]

А, разве Model::query()->toBase() не тоже самое?

[65536]

Оно! Не знал

[necromant2005]

Знаете меня реально достала эта странная вырожденная идея с 3ей нормальной формой которую суют везде. В результате чего получаются монстры кеда чтоб вывести авторов статей нужно сделать N запросов или «хитро»-стандартный JOIN 2х таблиц по ключу. Вся эта сраная магия которая согласуется с реальностью от слова никак.

НЕ нужно хранить связанные данные отдельно. Храните себе данные домена — ВМЕСТЕ.
Данные об авторе рядом со статьей, теги тоже как часть статьи. А для сбора авторов — отдельно заботясь при сохранении в Repository. Или вообще отдельным процессом раз в день по крону. Ну не появится ваш супер пупер автор в туже секунду и что? Мир схлопнется — нет же. Никто его и не заметит. Тоже самое +1 тег для статьи влияет на общую картину тегов — от слова НИКАК. Потому что 1 тег << 100500 других тегов в 1000+ статей

[pbatanov]

Данные об авторе рядом со статьей, теги тоже как часть статьи

Как в этом случае отличить двух одинаковых авторов (условные тезки) от одного и того же?
Как в этом случае исправить опечатку в фамилии автора не нагнув всю базу обновлением всех документов?
Что происходит с автором, если удаляется последняя его статься? данные о нем канут в небытие?

Гораздо проще из нормальной формы сделать денормализованную через любого рода кэши или документные хранилища (типа эластика, например, если нужен поиск), чем наоборот, если вам нужны оптимизации, когда база разрастется. Т.е есть мастер данные, нормализованные и есть денормализованные рид-онли слепки с этих данных, с которыми работает сайт, если есть недостаток производительности реляционной модели.

У вас же на ровном месте на старте проекта есть какие-то кроны и обновления, даже если у вас всего 5 записей в БД.