Сводные таблицы и SQL: что выбрать для анализа данных

Нужно сравнить продажи по месяцам и регионам: в Excel вы соберёте сводную таблицу перетаскиванием полей, а в PostgreSQL опишете группировку запросом. Но это не взаимозаменяемые кнопка и язык: сводная таблица удобна для быстрого исследования данных, SQL — для повторяемого расчёта, который можно проверить и встроить в процесс. Сравниваем Excel для Microsoft 365 и PostgreSQL 16 на одной задаче.

Одна задача — два способа получить отчёт

Представим таблицу заказов с датой, регионом и суммой. Нужно получить выручку и число заказов по каждому месяцу и региону. В сводной таблице вы задаёте раскладку полей: месяц — в строки, регион — в столбцы, сумму и количество заказов — в значения. Excel агрегирует записи и строит матрицу.

В SQL вы задаёте те же правила запросом: какие строки взять, по каким полям сгруппировать и что посчитать. Результатом обычно будет список строк с месяцем, регионом, выручкой и количеством заказов. Чтобы сразу получить матрицу с регионами в колонках, понадобится дополнительное преобразование или слой визуализации.

Это важное различие: сводная таблица — интерактивный способ исследовать и представлять данные, SQL — способ точно описать выборку и расчёт. SQL не заменяет интерфейс отчёта, а сводная таблица не становится надёжным конвейером обработки данных.

Как выглядит расчёт в PostgreSQL 16

Ниже запрос для таблицы orders с полями order_date типа date, region и amount. Он считает показатели за 2025 год и выдаёт по одной строке на месяц и регион.

SELECT
    date_trunc('month', order_date)::date AS month,
    region,
    sum(amount) AS revenue,
    count(*) AS order_count
FROM orders
WHERE order_date >= DATE '2025-01-01'
  AND order_date < DATE '2026-01-01'
GROUP BY 1, 2
ORDER BY 1, 2;

В Excel та же логика задаётся через список полей сводной таблицы, а не через формулу запроса. Если строки добавляются в обычный диапазон, источник сводной таблицы может потребовать корректировки. Удобнее заранее оформить источник как таблицу Excel: новые строки тогда входят в её диапазон, но саму сводную таблицу всё равно нужно обновить, чтобы она пересчитала результат.

У SQL-запроса другая цена: сначала нужно знать структуру таблицы и правила расчёта. Зато запрос можно сохранить, положить под контроль версий и запускать повторно без ручного перетаскивания полей. Сам по себе он не создаёт интерактивный отчёт для коллег.

Сравнение: скорость старта против повторяемости

Агрегация* — сведение множества строк к показателям по выбранным группам: например, сумма продаж и количество заказов для каждого месяца.

Сводная таблица помогает быстро задать вопрос данным. SQL помогает сохранить точную формулировку ответа.

Когда выбирать сводную таблицу, а когда SQL

Оставьте задачу в Excel, если исследуете данные

Сводная таблица подходит, когда источник уже подготовлен, отчёт нужен для разового анализа, а разрезы ещё меняются. Можно быстро выяснить, какой регион просел, сравнить месяцы и проверить несколько вариантов группировки без отдельной разработки.

• Вы изучаете файл, а не строите регулярный отчёт для процесса.
• Нужно быстро менять строки, столбцы и фильтры без обращения к разработчику.
• Объём источника помещается в выбранный способ работы с книгой, а обновление данных можно контролировать вручную.

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

Переносите расчёт в SQL, если он должен повторяться

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

• Расчёт должен запускаться по расписанию или входить в другой процесс.
• Нужно согласовать единые правила между отчётами и командами.
• Важны проверка изменений и возможность понять, как получено число.

Цена — необходимость поддерживать запрос и разбираться с данными в базе. Ошибка в фильтре SQL тоже даст неверный отчёт, просто её легче увидеть и воспроизвести, если запрос сохранён. А интерактивный выбор разрезов придётся организовать отдельно.

Что ломается в обоих вариантах

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

Особенно внимательно относитесь к пустым значениям и дубликатам. count(*) в приведённом запросе считает строки, а не уникальные заказы: если один заказ представлен несколькими позициями, итог будет количеством строк. Для количества заказов тогда нужно считать уникальные идентификаторы заказов, которых в примере нет. Не подменяйте одну метрику другой только потому, что числа выглядят правдоподобно.

Ещё одна ловушка — даты. Пример рассчитан на поле типа date. Если источник хранит временные отметки с часовым поясом, границы суток и месяца могут зависеть от принятого бизнес-часового пояса. Сначала определите, по какому часовому поясу считать отчёт, и только затем сравнивайте результаты с Excel.

Наконец, обновление — не то же самое, что получение актуальных данных. Сводная таблица пересчитает источник после обновления, но это не гарантирует, что сам источник уже содержит свежую выгрузку. SQL запросит данные из базы, но актуальность зависит от загрузки данных и выбранных условий.

Что сделать дальше

Возьмите один показатель — например, выручку за месяц — и зафиксируйте его определение: какие заказы включать, какую дату считать датой продажи и как обрабатывать возвраты. Затем соберите сводную таблицу и SQL-результат на одном и том же источнике и сравните суммы по нескольким месяцам и регионам. Если числа расходятся, ищите разницу в источнике, фильтрах и детализации, а не выбирайте инструмент, который показал более удобный ответ.

Когда расчёт совпадёт, решите, кому нужен результат: для исследования оставьте удобную сводную таблицу; для регулярного отчёта сохраните SQL-запрос и определите, как он будет запускаться и проверяться. Отдельная тема — построение кросс-таблицы непосредственно в SQL; здесь сравниваются способы получить и поддерживать агрегированный отчёт.