MySQL Выполнение нескольких запросов для сохранения СУХОГО кода, проблемы с производительностью?
Чтобы сохранить мой код СУХИМ, в настоящее время у меня есть несколько отдельных запросов, которые имеют свои обязанности. Это позволяет мне выполнять сложные действия, используя комбинацию этих запросов вместо того, чтобы писать большие запросы, настроенные только для этих действий.
Подобно тому, как в вашем коде используются повторно используемые / динамические методы вместо написания одного метода для каждого конкретного варианта использования. Это облегчает разработку, но потенциально за счет некоторой производительности.
ЗаметкаЯ не держу это СУХОЙ просто ради СУХОГО. Я стараюсь, чтобы все было динамично и легко читалось & Понимаю.
Упрощенный пример:
Мне нужно получить группы разрешений для сотрудника и отдела. Затем мне нужно получить ассоциации разрешений для этих групп разрешений. Мне также нужно получить подробные разрешения, назначенные сотруднику или отделу (разрешения, не связанные с группой разрешений).
Я мог бы написать 2 запроса, чтобы получить группы разрешений и связанные с ними разрешения с помощью объединений, и еще 2 запроса, чтобы получить разрешения, непосредственно связанные с сотрудниками и отделами. Они не могут быть повторно использованы для других целей.
Или я мог бы написать 1 запрос, чтобы получить группы разрешений для сотрудников или отделов, 1 запрос, который получает разрешения, связанные с любой группой разрешений, и 1 запрос, который может получить разрешения, связанные с самими сотрудниками / отделами.
- 4 определенных одноразовых запроса, 4 выполнения, 4 вызова методов из API
- В.С.
- 3 многоразовых / динамических запроса, 6 выполнений, 1 вызов метода из API
Это упрощенный пример. На практике у меня было бы более 15 конкретных запросов и 15 выполнений. Против 5 динамических запросов и ~ 40 выполнений.
Есть ли проблемы с производительностью, если вы решите это? Сам код кажется намного чище и с ним легче работать, но я не хочу жертвовать значительным объемом производительности БД для более чистого dev-API.
Решение
Вы должны попытаться использовать наименьшее количество запросов на страницу запроса. Даже если они быстрые, представьте, что у вас есть 5 выполнений запросов на странице против 40. Если на эту страницу заходит 1000 человек, то это 5000 запрошенных запросов против 40 000. Да, вы можете включить кеширование, но я бы на это не полагался. Даже если он включен, ваша производительность все равно будет лучше, если использовать меньше запросов. Если вам нужно получить результаты для 5 кэшированных запросов, это, очевидно, быстрее, чем получить результаты для 40. Если ваши индексы определены правильно и актуально, если вам нужно сделать несколько объединений, ваши запросы все равно должны выполняться быстро , Я думаю, что независимо от того, какие ответы вы получите здесь, вы все равно должны пробовать и ошибаться и регистрировать результаты. Если мы говорим здесь о разнице в миллисекундах, а вы не получаете тысячи запросов страниц каждую минуту, тогда это действительно имеет значение?
Другие решения
Несколько десятков простых запросов не слишком много для веб-страницы.
Попробуйте оба способа. Попробуйте третий подход к запросам. Пусть это будет учебное упражнение. Не обязательно есть «правильный» способ разработки / кодирования того, что вы описали.
СУХОЙ — хороший принцип, но он может быть слишком сложным. Итак, ищите «правильный баланс» между различными подходами.
Распространенной мантрой является «избегать преждевременной оптимизации».
detector