данных Расчеты MySQL против Python

Question

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

1. Расчет данных с использованием Python из вывода запроса MySQL.
2. Выполняйте вычисления в самом запросе.

Например, запрос возвращает 20 строк с 10 столбцами. В Python я вычисляю разницу или деление некоторых столбцов.

Лучше ли это сделать в запросе или в Python?

Answer 1

Это, вероятно, дело вкуса, но ...

... чтобы дать вам прямо противоположный ответ, как один за Алма Do Mundo, для (не так) простой расчет сделанный на SELECT ... , я обычно пытаюсь использовать БД «как калькулятор».

Расчеты (в предложении SELECT ...) выполняются как последний шаг при выполнении запроса. На данный момент используются только соответствующие данные. Вся «большая работа» уже выполнена (обработка JOIN, где предложения, агрегаты, сортировка).

На данный момент нагрузка на выполнение некоторых арифметических операций с данными действительно мала. И это уменьшит сетевой трафик между вашим приложением и сервером БД.

Это, вероятно, дело вкуса мысли ...

Answer 2

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

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

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

Для такого подхода «чтение» доступа к базе данных будет осуществляться через представления. Логика, о которой вы говорите, войдет в представления и будет доступна любому пользователю базы данных - обеспечивая согласованность между различными функциями с использованием базы данных. «запись» будет осуществляться через хранимые процедуры, гарантируя, что бизнес-правила будут проверяться последовательно и что операции будут регистрироваться соответствующим образом.