Андрей, Ничем плохим это не является, но если хочется уменьшить число запросов то можно сделать методы-агрегаторы или поставить GraphQL сервер. На ранних стадиях проекта не стоит так заморачиваться. Вот когда число запросов вырастет в десятки и поддерживать это станет тяжело - стоит задуматься
Андрей, Это все именно в моделях и прописывается. Если у вас вызовы plain SQL то у меня для вас плохие новости и рекомендация хотябы на Query Builder перевести
Андрей, вас больше нуля и вы не понимаете что делаете именно по тому что не программист и практически с нуля. У вас уже проблема ив поддержке, а вряд ли там проект большой.
Базу тоже всегда можно мигрировать если она больше ни к чему не приколочена
lil_web, тут явно какая-то фигня. Хочется делать все и сразу - оборачиваем все в GraphQL, не хочется - не оборачиваем. Число запросов к серверу от этого меньше не станет ибо не так много кейсов когда он работает напрямую с базой данных и больше с REST микросервисами. И REST хотябы позволяет валидировать запросы, а GraphQL валидирует только схему.
lil_web, если владелец сайта говорит что вы не можете делать у нему больше одного запроса то значит что у них проблема в архитектуре и отсутствии масштабирования. И вообще - что значит одного запроса? В какой период времени?
Алексей Николаев, у меня хватает примеров как хорошие специалисты там работают и по 10+ лет. Когда выходишь на международный рынок то всегда есть какие-то последствия. В данном случает такие организации как DataArt или Accenture отличаются только размером
alex-1917, слово нужные в архитектуре не существует. Если не указан список это значит что собирать необходимо все по тому что для анализа никто не знает что потребуется отображать/агрегировать
Иван Иванов, Из коробки нет ни у кого. В постгре надо настраивать как я помню и все это изначально плохая затея по тому как поддерживать без проф.DBA невозможно. Вносить изменения тяжело и больно. А если появится необходимость заменить базу так и вообще можно сразу будет об этом забыть
DamskiyUgodnik, нет, это не быстрее. Колик работает все-же по сокету и асинхронен. Смысл в том чтобы доставлять большое число отдельных сообщений с конфирмом каждого. И пропускная способность у него огромная. Если ее хватает то или кафку ставить или тюнить/масштабировать
Kerm, в настройках, очевидно) это единственное место. Там все отступы и шаблоны редактируются только в путь, но это делают очень редко и только под особые требования. Из коробки то что шторм делает иначе не означает что он делает это хуже
zhulan0v, смотреть можно одновременно только на один монитор. Если часто на него смотреть то значит что код пишется плохо, больно и нужно постоянно проверять. Опытный разработчик проверяет в основном готовый модуль или компоненту, не более.
Рамки между мониторами давно почти миф ибо есть почти безрамочные мониторы с толщиной этой самой рамки в 1мм и менее.
Когда делится большой монитор на несколько частей по появляется проблема смещенного центра зрения и со временем глаза отвыкают смотреть прямо что очень не приятно со временем
