MySQL Запуск нескольких запросов для сохранения кода DRY, проблемы с производительностью?

Question

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

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

Примечание: Я не хранил его СУХОЙ только ради СУХОЙ. Я пытаюсь держать вещи динамичными и легко читать & понять.

Упрощенный пример:

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

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

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

• 4 Конкретные Non-многоразовые Запросы, 4 казни, 4 метод вызывает из API
• VS
• 3 многоразовые/Динамические запросы, 6 казней, 1 вызов метода из API

---

Это упрощенный пример. На практике у меня было бы 15 запросов к конкретным случаям и 15 казней. Vs 5 динамических запросов и ~ 40 исполнений.

Есть ли проблемы с производительностью при движении по этому пути? Сам код выглядит намного чище и с ним легче работать, но я не хочу жертвовать значительным количеством производительности DB для более чистого dev-API.

Answer 1

Вы должны попытаться использовать наименьшее количество запросов, доступных на запрос страницы. Даже если они бывают быстрыми, представьте, что у вас есть 5 запросов на странице против 40. Если 1000 человек попали на эту страницу, это 5000 запросов, запрошенных против 40 000. Да, вы можете включить кеширование, но я бы не стал полагаться на него. Даже если он включен, ваша производительность будет по-прежнему лучше использовать меньше запросов. Если вам нужно получить результаты для 5 кэшированных запросов, это, очевидно, быстрее, чем получение результатов для 40. Если ваши индексы определены правильно и обновлены, если вам нужно сделать несколько объединений, ваши запросы все равно будут выполняться быстро , Я думаю, что независимо от того, какие ответы вы получите здесь, вы все равно должны проб и ошибок и запишите результаты. Если мы говорим о разнице в миллисекундах, и вы не получаете тысячи запросов страниц каждую минуту, значит, действительно ли это имеет значение?

Answer 2

Несколько десятков простых запросов не слишком много для веб-страницы.

Попробуйте оба способа. Попробуйте третий подход к запросам. Пусть это будет учебное упражнение.Не обязательно «правильный» способ разработки/кодирования того, что вы описали.

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

Общая мантра - это «преждевременная оптимизация».