🗄️ SQL

Короткий ответ INNER JOIN оставляет строки только при совпадении с обеих сторон. LEFT JOIN дополнительно сохраняет несовпавшие строки левой таблицы, заполняя столбцы правой стороны значениями NULL. Как это работает подробнее Условие в ON определяет пары строк. Если одной строке слева соответствуют три строки справа, соединение создаст три строки независимо от вида соединения. Поэтому LEFT JOIN гарантирует сохранение левых строк, но не гарантирует, что итоговое количество строк равно числу строк слева: связь один-ко-многим увеличивает результат. Сравнение INNER JOIN — нужны только объекты со связанной записью — несовпавшие строки исключаются. LEFT JOIN — нужно сохранить все объекты слева — справа возможны NULL. Пример кода Что использовать на практике Сверяйте гранулярность. До соединения определите, уникален ли ключ в правой таблице. Считайте отсутствующие связи. После LEFT JOIN используйте COUNT(o.order_id), а не COUNT(*), чтобы клиент без заказов получил ноль. Подводные камни Потеря строк. INNER JOIN исключ

Читать полностьюinner-join

Короткий ответ QUALIFY позволяет фильтровать строки прямо по значению оконной функции в том же SELECT, где она вычислена, тогда как в PostgreSQL (где QUALIFY не поддерживается) для этого нужно обернуть оконную функцию в подзапрос или CTE и фильтровать уже внешним WHERE, потому что WHERE не может напрямую ссылаться на оконные функции, вычисленные в том же уровне запроса. Как это работает подробнее логический порядок выполнения запроса — оконные функции вычисляются после WHERE, но до финальной проекции SELECT; QUALIFY — это дополнительный этап фильтрации именно после вычисления оконных функций, аналогичный тому, как HAVING работает после GROUP BY. В PostgreSQL такого отдельного этапа нет, поэтому оконную функцию нужно материализовать в подзапросе/CTE, чтобы потом сослаться на неё в обычном WHERE. Пример кода Что использовать на практике Практика. QUALIFY делает запрос короче и нагляднее там, где он поддерживается; в PostgreSQL эквивалентная логика требует дополнительного уровня вложенности, что не хуже по произ

Читать полностьюbigquery

Короткий ответ Нужно пронумеровать строки по order_id с сортировкой по updated_at DESC через ROW_NUMBER(), оставить только строки с номером 1 (последнюю версию каждого заказа) в CTE, и уже на этом «чистом» наборе строить все дальнейшие агрегаты. Как это работает подробнее этот паттерн — частный случай дедупликации (аналогичный вопросу про удаление дублей), но применяется систематически как обязательный первый шаг перед любой агрегацией таких данных, а не разово; логика та же: PARTITION BY order_id ORDER BY updated_at DESC даёт rn = 1 для самой свежей версии. Пример кода Что использовать на практике Практика. важно убедиться, что updated_at действительно монотонно отражает «более новую» версию записи, а не время технической вставки строки в хранилище — если источник присылает исторические правки с запаздыванием, именно бизнес-метка времени обновления должна использоваться для сортировки, а не момент загрузки в хранилище. Проверка. Проверка: COUNT(DISTINCT order_id) на latest WHERE rn = 1 должен равняться COUNT

Читать полностьюdeduplication

Короткий ответ Нужно сравнить определения метрики и границы фильтров в обоих местах (период, статусы заказов, включены ли возвраты/отмены, часовой пояс), а затем по шагам сузить расхождение через разбивку по дням/статусам/источникам, а не сразу искать ошибку в коде дашборда. Как это работает подробнее Как это работает: расхождение в 8% редко означает «дашборд врёт» — чаще это разные правила агрегации: например, дашборд может фильтровать status != 'cancelled', а отчёт источника считает все заказы; или дашборд использует order_date, а отчёт — payment_date; или часовой пояс границы месяца отличается (см. вопрос про UTC). Пример кода Что использовать на практике На практике: эффективный порядок проверки: (1) сравнить фильтры WHERE/статусы в обоих запросах построчно; (2) разбить расхождение по дням — если оно сосредоточено у границ месяца, это сигнал про часовой пояс или про дату отсечки; (3) разбить по статусу заказа и источнику — если расхождение сосредоточено в одной категории, искать там; (4) сверить итоговую

Читать полностьюaggregation

Короткий ответ Безопаснее использовать полуоткрытый интервал order_date >= '2024-03-01' AND order_date , чем BETWEEN '2024-03-01' AND '2024-03-31', особенно если order_date хранится как timestamp, а не как чистая дата. Как это работает подробнее BETWEEN a AND b эквивалентно >= a AND . Если поле — date, BETWEEN '2024-03-01' AND '2024-03-31' действительно включает весь март. Но если поле — timestamp, то '2024-03-31' интерпретируется как полночь 2024-03-31 00:00:00, и заказы, сделанные позже полуночи 31 марта (например, в 15:00), в диапазон не попадут. Пример кода Что использовать на практике На практике: полуоткрытый интервал [начало месяца, начало следующего месяца) работает одинаково надёжно независимо от того, date это или timestamp, и его проще обобщить на произвольный период, вычисляя границы динамически. Результат: Результат — все заказы марта 2024, включая сделанные в последнюю секунду 31 марта. Проверка: сравнить максимум order_date в результате с максимумом order_date по всей таблице за март, отфильтро

Читать полностьюbetween

Короткий ответ Нужно использовать LAG(revenue, 12) OVER (ORDER BY month) вместо LAG(revenue, 1, ...), чтобы сравнивать каждый месяц не с предыдущим, а с тем же месяцем год назад — это сравнение год-к-году (YoY) корректно учитывает сезонность. Как это работает подробнее параметр n в LAG(column, n) задаёт, на сколько строк назад по заданному порядку смотреть; если ряд строго помесячный без пропусков, n = 12 сдвигает на 12 месяцев назад, то есть на тот же календарный месяц предыдущего года. Пример кода Что использовать на практике Практика. сравнение месяц-к-месяцу (MoM) часто вводит в заблуждение для сезонных продуктов (например, продажи ёлочных игрушек в январе логично падают относительно декабря — это не признак проблем с продуктом), поэтому для таких бизнесов сравнение YoY даёт более содержательную картину. Важно убедиться, что ряд действительно непрерывен (нет пропущенных месяцев), иначе LAG(..., 12) «сдвинется» не на 12 календарных месяцев, а на 12 существующих строк, что не одно и то же при пропусках. Про

Читать полностьюdate-trunc

Короткий ответ Нужно сгруппировать таблицу по этим двум столбцам, посчитать количество строк в каждой группе через COUNT(*) и отобрать группы с HAVING COUNT(*) > 1 — это и есть дубликаты. Как это работает подробнее GROUP BY email, order_date объединяет все строки с одинаковой комбинацией этих значений в одну группу; COUNT(*) в каждой группе показывает, сколько исходных строк туда попало, а HAVING отфильтровывает только те группы, где это число больше 1. Пример кода Что использовать на практике На практике: перед любой агрегацией метрик (суммы, средние) полезно сначала явно проверить данные на дубликаты именно таким запросом — это быстрый и наглядный способ понять масштаб проблемы до того, как строить отчёт. Дубликаты могут появляться из-за повторной выгрузки данных, сбоя в ETL или неправильного JOIN на предыдущем шаге. Результат: Если результат пустой — дубликатов по этой комбинации нет. Проверка: для одной найденной пары email+дата вручную просмотреть все строки через SELECT * FROM orders WHERE email = ... A

Читать полностьюdata-quality

Короткий ответ Нужно сравнить общее количество строк в таблице с количеством уникальных значений этого столбца: SELECT COUNT(*), COUNT(DISTINCT order_id) FROM orders; — если числа совпадают, столбец уникален. Как это работает подробнее COUNT(*) считает все строки, а COUNT(DISTINCT order_id) — только уникальные значения столбца; если order_id действительно не повторяется, оба числа будут равны. Если второе число меньше первого, значит есть повторяющиеся значения. Пример кода Что использовать на практике эту проверку стоит делать перед тем, как использовать столбец как ключ соединения (JOIN) — если ожидаемый уникальный ключ на самом деле содержит дубликаты, JOIN по нему может незаметно размножить строки («fan-out») и искажённо увеличить последующие суммы. Если total_rows = 5000 и unique_ids = 4980, значит есть 20 «лишних» дублирующихся строк, которые нужно расследовать отдельным запросом с GROUP BY order_id HAVING COUNT(*) > 1. Подводные камни проверяют уникальность только «на глаз», просматривая первые несколь

Читать полностьюdata-quality

Короткий ответ Правдоподобная цифра не доказывает корректность. Начните с формулировки зерна каждой CTE и ожидаемой кардинальности каждого соединения, затем проверьте результат на малом наборе с известным ответом. Как это работает подробнее Fan-out выявляют сравнением количества строк, уникальных бизнес-ключей и сумм до и после JOIN. Для связи many-to-many нужна предварительная агрегация или явная bridge-таблица. Диапазоны времени безопаснее писать как timestamp >= start AND timestamp . Это избегает двойного учёта границы и проблем с точностью. SRM проверяют по числу единиц рандомизации, а не по числу событий. Пример кода Что использовать на практике Требуйте инварианты. Автор заранее пишет, что должно сохраняться и в каких пределах. Проверяйте данные, а не стиль. Форматирование автоматизируется, смысл зерна — нет. Соразмеряйте глубину. Продакшен-дашборд требует строже ревью, чем одноразовый низкорисковый срез. Подводные камни SUM после one-to-many JOIN. Сумма повторяется для каждой дочерней строки. BETWEEN д

Читать полностьюcode-review