Один сложный запрос vs Несколько простых запросов

Что на самом деле лучше? Есть классы со сложными запросами, ответственными за загрузку, например, вложенных объектов? Или классы с простыми запросами, ответственными за загрузку простых объектов?

С сложными запросами вам нужно меньше обращаться к базе данных, но класс будет нести большую ответственность.

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

Ситуация, в которой я находилась, заключается в том, что загруженные объекты будут отправлены в приложение Flex (DTO).

Ответ 1

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

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

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

Чаще всего приходится исправлять системы с ужасной производительностью, в основном из-за выполнения отдельных запросов (в частности, коррелированных запросов) вместо соединений.

Ответ 2

Я не думаю, что любой вариант на самом деле лучше. Это зависит от специфики вашего приложения, архитектуры, используемой СУБД и других факторов.

например. мы использовали несколько простых запросов в нашем автономном решении. Но когда мы разработали наш продукт в отношении облегченного доступа к интернету, мы обнаружили, что наша инфраструктура сделала огромное количество запросов и что это привело к потере производительности сети. Поэтому мы достаточно переработали наши рамки для использования агрегированных сложных запросов. Тем временем мы все еще поддерживали наше автономное решение и перешли от Oracle Light к Apache Derby. И еще раз мы обнаружили, что некоторые из наших новых сложных запросов должны быть упрощены, поскольку Derby слишком долго их выполнял.

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

Ответ 3

Из чувства кишки я бы сказал:

Идите простым способом, пока нет доказанной причины для оптимизации производительности. В противном случае я бы поставил подход "сложные объекты и запрос" в корзину преждевременной оптимизации.

Если вы обнаружите, что есть реальные последствия для производительности, то на следующем шаге вы должны оптимизировать кругооборот между flex и backend. Но, как я сказал раньше: это чувство кишки, вы действительно должны начать с определения "исполнитель", начать просто и измерить производительность.