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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

С чувством кишки я бы сказал:

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

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