Один сложный запрос vs Несколько простых запросов
Что на самом деле лучше? Есть классы со сложными запросами, ответственными за загрузку, например, вложенных объектов? Или классы с простыми запросами, ответственными за загрузку простых объектов?
С сложными запросами вам нужно меньше обращаться к базе данных, но класс будет нести большую ответственность.
Или простые запросы, в которых вам нужно будет больше обращаться к базе данных. В этом случае, однако, каждый класс будет нести ответственность за загрузку одного типа объекта.
Ситуация, в которой я находилась, заключается в том, что загруженные объекты будут отправлены в приложение Flex (DTO).
Ответы
Ответ 1
Общее правило заключается в том, что серверные обратные трассы дороги (относительно того, как долго типичный запрос берется), поэтому основным принципом является то, что вы хотите минимизировать их. В принципе, каждое соединение "один-ко-многим" потенциально может умножить ваш результирующий набор таким образом, чтобы я приближался к нему, чтобы поддерживать соединение до тех пор, пока набор результатов не станет слишком большим или время выполнения запроса не станет слишком длинным (примерно 1-5 секунд в целом).
В зависимости от вашей платформы вы можете или не можете выполнять запросы параллельно. Это ключевой детерминант в том, что вы должны делать, потому что, если вы можете выполнять только один запрос за раз, то барьер для разбивки запроса намного выше.
Иногда стоит хранить некоторые относительно постоянные данные в памяти (например, информацию о стране) или делать их как отдельный запрос, но это, по моему опыту, достаточно необычно.
Чаще всего приходится исправлять системы с ужасной производительностью, в основном из-за выполнения отдельных запросов (в частности, коррелированных запросов) вместо соединений.
Ответ 2
Я не думаю, что любой вариант на самом деле лучше. Это зависит от специфики вашего приложения, архитектуры, используемой СУБД и других факторов.
например. мы использовали несколько простых запросов в нашем автономном решении. Но когда мы разработали наш продукт в отношении облегченного доступа к интернету, мы обнаружили, что наша инфраструктура сделала огромное количество запросов и что это привело к потере производительности сети. Поэтому мы достаточно переработали наши рамки для использования агрегированных сложных запросов. Тем временем мы все еще поддерживали наше автономное решение и перешли от Oracle Light к Apache Derby. И еще раз мы обнаружили, что некоторые из наших новых сложных запросов должны быть упрощены, поскольку Derby слишком долго их выполнял.
Итак, посмотрите на свою реальную проблему и решите ее соответствующим образом. Я думаю, что простые запросы хороши для начала, если против них нет сильных целей.
Ответ 3
Из чувства кишки я бы сказал:
Идите простым способом, пока нет доказанной причины для оптимизации производительности. В противном случае я бы поставил подход "сложные объекты и запрос" в корзину преждевременной оптимизации.
Если вы обнаружите, что есть реальные последствия для производительности, то на следующем шаге вы должны оптимизировать кругооборот между flex и backend. Но, как я сказал раньше: это чувство кишки, вы действительно должны начать с определения "исполнитель", начать просто и измерить производительность.
