1

SQL и Python: один запрос - два разных способа думать

Серия Аналитика FM

Сейчас у аналитика для работы с данными есть два популярных "инструмента" - это SQL и Python.

Часто слышу, что SQL считают "жестким", а Python - "гибким" инструментом в аналитике.

На самом деле разница не в гибкости между этими языками, а в "модели выполнения"

Ниже сравним один и тот же пример реализованный SQL и Python. И проследим, что выполняется на каждом шаге.

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

  1. Взять только оплаченные заказы

  2. Посчитать сумму заказов по пользователям

  3. Оставить пользователей, у которых сумма больше 10 000

  4. Отсортировать по убыванию суммы

Как это выглядит в SQL

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

  1. FROM — база берёт таблицу orders

  2. WHERE — отфильтровывает только status = 'paid'

  3. GROUP BY — группирует строки по user_id

  4. SUM(amount) — считает сумму внутри каждой группы

  5. HAVING — отбрасывает группы с суммой ≤ 10 000

  6. SELECT — формирует финальные колонки

  7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

  1. Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

  • пользователей

  • их суммы

  • можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

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

Python

- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000

Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

0
Автор поста оценил этот комментарий

SQL не идёт шаг за шагом как сценарий.

План запроса с вами поспорит. Здесь алгоритм строит не программист, а планировщик/оптимизатор в процессе выполнения запроса. Юзер может лишь косвенно влиять на процесс.


- нет "текущего состояния"

А ведь транзакции зачем-то нужны, курсоры, да и сами результаты запросы умеют стриммиться в клиента по мере готовности. Рекуррентные CTE тоже намекают на наличие стейта. Он недоступен клиенту, будучи под абстракцией, но это же не значит, что его нет.

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

"План запроса с вами поспорит. Здесь алгоритм строит не программист, а планировщик/"
- В этом то и суть, что в SQL это делает не программист, а планировщик, а в Python - как программист написал, так и будет последовательно выполняться.


- в SQL group by x,y,x является частью описания результата, а в Python - это отдельная операция над данными.

ну когда мы пишем, например CTE, то это не гарантирует нам, что СУБД выполнит первым, оптимизатор может все переписать.

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества