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

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

Сначала зафиксируйте, что именно считаете

Инструменты дадут одинаковый результат, только если совпадает определение показателя. Для примера примем, что таблица sales содержит одну строку на продажу, дату без времени, категорию, сумму и статус. В отчёт входят только строки со статусом paid; возвраты и отмены здесь не учитываются.

Перед построением отчёта ответьте на четыре вопроса:

• Что считается одной строкой: заказ, позиция заказа или платёж? Если в заказе несколько товаров, сумма по строкам и сумма по заказам — разные показатели.
• Какие статусы включать? Фильтр по всем строкам может незаметно добавить отмены или неоплаченные заказы.
• Как трактовать пустую категорию и пустую сумму: показывать отдельно, считать нулём или исключать?
• Какой период означает «месяц»? Для даты без времени граница проста; для временных меток нужно сначала определить часовой пояс.

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

Подход 1. Сводная таблица в Excel

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

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

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

Подход 2. SQL-запрос в PostgreSQL 16

SQL выгоднее, когда расчёт должен быть повторяемым, проверяемым и общим для команды. Ниже запрос для указанной схемы; поле sale_date имеет тип date, а amount — числовой тип. Запрос группирует оплаченные продажи по месяцу и категории.

SELECT
    date_trunc('month', sale_date)::date AS month,
    category,
    SUM(amount) AS sales_total
FROM sales
WHERE status = 'paid'
GROUP BY 1, 2
ORDER BY 1, 2;

Фильтр виден в запросе, группировка задана явно, а результат можно повторить на тех же данных. Здесь месяц начинается с первого числа, категория с пустым значением останется пустой группой. Если хотите подписать её «Не указана», замените поле в выборке и группировке на COALESCE(category, 'Не указана'). Не подменяйте пустую сумму нулём без решения владельца показателя: это разные состояния данных.

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

Подход 3. SQL для расчёта, таблица для изучения

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

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

Сводная таблица отвечает на вопрос «как быстро посмотреть данные?». SQL — на вопрос «какое именно правило расчёта команда будет повторять?».

Сравнение подходов

Как выбрать и проверить результат

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

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

1. Зафиксируйте период, статусы, валюту, правила для возвратов и пустых значений. Проверка: все участники могут описать показатель одним и тем же предложением.
2. Возьмите небольшой отрезок исходных данных и соберите по нему оба отчёта. Проверка: совпадают месяцы, категории и сумма для каждой группы.
3. Если суммы расходятся, сравните количество строк после фильтра, затем проверьте дубли и зерно данных. Проверка: вы можете объяснить разницу конкретными записями, а не предположением.
4. Добавьте строку с известной датой, категорией и суммой, обновите сводную и повторите запрос. Проверка: новая запись попала в нужную группу один раз.

Что ломается чаще всего

• Сводная не видит новые строки. Проверьте источник и обновите отчёт. Если использован обычный диапазон, расширьте его; для будущих добавлений удобнее источник в виде таблицы Excel.
• Итоги отличаются на сумму возвратов. Сверьте условия включения статусов и то, хранятся ли возвраты отдельными строками или отрицательными суммами.
• В SQL слишком большая сумма. Проверьте, не размножает ли соединение строки и не хранится ли сумма заказа в каждой позиции. Сначала сравните число строк до и после соединений.
• Месяц в отчёте сдвинут. Для примера выше используется тип date. Если в таблице время, уточните его тип и часовой пояс до группировки; преобразование временной метки в локальную дату может менять месяц на границе суток.

Производительность нельзя честно сравнить без объёма данных, устройства, настроек и одинаковых условий запуска. Если скорость — причина выбора, измерьте отдельно время обновления сводной и выполнения SQL на той же выборке; зафиксируйте число строк, оборудование и наличие сетевой задержки. Не делайте вывод по одному запуску: кэширование и фоновые задачи могут повлиять на результат.

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

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