Серия «SQL: знакомство»

Я задалась себе вопросом: а зачем сейчас, в эпоху искусственного интеллекта, изучать языки программирования?

Об этом порассуждаю ниже.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL.
Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Разбор задач со скользящим окном уже в канале.
Присоединяйся!

И так

Сейчас нейросети могут создавать "много чего". Могут в принципе написать план создания отдельного государства. Я почти уверена, что каждый второй точно пользуется нейросетями для облегчения своей жизни. Почти каждая компания говорит о том, что выполнение рутинных задач будут замещены ИИ. Это и хорошо и плохо, как говорится, у любой стороны есть две медали. С одной стороны мы сможем освободившееся время выделить на что-то другое, а с другой стороны - это изменение в штатном расписании.

Так зачем же сейчас изучать SQL, если есть ИИ, который за нас может написать весь код, мы даже можем загрузить сырые данные и попросить проанализировать его, что это за данные, чтобы потом, при постановке задачи, учесть все нюансы в промте.

Рассмотрим следующий кейс:

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

Ты открываешь ИИ и говоришь:

Вот данные. Напиши SQL-запрос, который посчитает эти метрики. Учти NULL, особенности данных и вот эти условия

Все перечислил, все вроде бы учел.

ИИ пишет запрос.
Он выглядит красиво. Он даже выполняется.
Цифры выводятся.

И вот здесь возникает главный вопрос:
а что именно ты получил?

Ты дал данные, ИИ проанализировал, составил запрос, учел там формат даты, NULL и т.п., выдал результат. А как понять - можно ли верить этим данным? А почему получилось именно это число?

Т.е. появляется вопрос: а почему именно так?

Тут ты также можешь задавать вопросы нейросети и выяснять почему получились именно такие данные. Чтобы задавать такие вопросы знание SQL вообще не нужно. Нужно понимание полученных результатов. И все вопросы, которые ты задаешь - это бизнес-вопросы.

Нейросеть тебе на твои уточняющие вопросы дает комментарии и в этот момент, ты либо веришь полученным ответам, либо идешь проверять.

А чтобы проверить, тебе надо лезть в данные. И вот тут знания SQL тебе явно пригодятся.
Ты можешь от ИИ получать на вопрос: "Почему выросла конверсия?", например, такие ответы: "Конверсия выросла из-за изменения структуры пользователей."

И что делать с таким ответом?
В твоей голове аналитика сразу возникают следующие вопросы:
- каких именно пользователей
- с какого дня
- по каким условиям
- что было исключено из расчета

Ты и эти вопросы можешь задавать нейронке.
Но без SQL ты можешь остаться на уровне объяснений, а не на уровне доказательств.

По факту:

SQL нужен не для того, чтобы:

• писать сложные запросы

• помнить синтаксис

• быть «технарём»

SQL нужен, чтобы в любой момент сказать:

«Я могу сам(а) проверить».

Это ключевое.

Не написать с нуля.
Не оптимизировать на миллионы строк.
А проверить логику расчёта на уровне данных.

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

И тут ты возвращаешься к началу. Чтобы задать корректный промт для нейросети, ты должен сначала проанализировать данные, чтобы учесть все условия для вычисления показателей.

А чтобы проанализировать нужно самому написать SELECT-ы различного рода.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.

Подписывайся!

Сегодня последний день 2025 года.
И даже не крайний, как многие любят говорить.

Вообще, 31 декабря - это не про чтение постов.

Это про:

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

Поэтому пусть этот пост будет просто точкой.
Тихой, спокойной точкой в конце года.

Хочу пожелать вам в эту предновогоднюю суету уюта.
Не обязательно идеального праздника - а именно уюта.
Чтобы было тепло, спокойно и по-человечески хорошо.

А если вдруг вы из тех, кто 31 декабря всё равно думает про цифры, данные и "а что там в статистике за год" - оставлю здесь ссылку на свой телеграм-канал.

На связи SQL

Там я пишу про SQL и базы данных:
- как не бояться JOIN
- зачем нужен GROUP BY
- почему NULL ≠ 0
- и как вообще начать понимать, что происходит в запросах

Ну и разбор задач по накопительной сумме и скользящему окну уже выложены

Канал я веду с нуля подписчиков, без крика и без пафоса.

Но сегодня - не об этом.
Сегодня просто до встречи в новом году 🤍
Берегите себя и пусть 2026 будет чуть добрее.

В далекие времена после университета, я работала специалистом по качеству данных.
Данные были клиентские: ФИО, адреса, телефоны, email. И надо было, чтобы данные были качественные. Для этого в компании использовалось ПО по стандартизации данных, надо было следить, чтобы ПО работало корректно, если замечаешь, что при обработке допущена ошибка, то выставляешь ТЗ на доработку, проверяешь, чтобы новый релиз работал как минимум не хуже чем предыдущий ну и т.д.

Так вот, хоть я и работала с клиентскими данными, но я не работала с БД. Хотя все данные лежали в БД. У меня там были выгрузки в Excel, их формировал кто-то другой. И я в Excel обрабатывала эти данных - надо было, чтобы процент плохих или неразобранных данных был меньше 3.

Перешла я в другую компанию - тоже на проект с качеством клиентских данных. И тут мне предлагают: "а давай мы тебе доступ к БД дадим, ты там будешь селектики делать, статистику считать". И тут у меня загорелись глаза. "Да, конечно, я хочу, но я ничего не знаю, не знаю как пользоваться, хотя в универе у меня был курс, связанный с базами данных. Но я ничего не помню. Так у меня началось осознанное знакомство с SQL.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0.
Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Глаза горели, а руки делали в тот момент. Я начала знакомится, что такое БД, DWH, а потом стали появляться Data Lake.

Все эти слова (База данных, DWH, Data Lake) - это про совокупность данных. Везде здесь могут быть связи. Везде может использоваться одна и та же технология (PostgreSQL, S3, ClickHouse и т.д.)

Почему же, если это все про совокупность данных, стали появляться разные слова для этого?

Посмотрим на кусок мяса.
Мы его можем варить, жарить, мариновать.
Но это все равно остается мясом.

Получается, что мясо - это сырье.
А стейк, бульон, котлета - это не мясо, а БЛЮДА.

А теперь попробуем сделать проекцию на данные.

Данные = мясо.
БД/DWH/Data Lake - не мясо, а способ организации этого мяса

База данных - это технология хранения
DWH и Data Lake - это концепции организации данных

У DWH есть своя БД
У Data Lake - своя БД
Но не каждая БД - это DWH
И не каждая БД - это Data Lake

База данных - это как холодильник. Он хранит еду, ему все равно, будет ли это суп или торт.
БД - это "контейнер + правила":
- как хранить данные
- как читать
- как писать
- как обеспечивать целостность

БД Не говорит - зачем хранить эти данные, как они буду использоваться.

Что же такое DWH?

Это ближе уже к готовому блюду. Его не переделывают, его едят и анализируют (это в идеале, конечно)

В DWH данные:
- приведены к единому виду
- нормализованы (чаше всего встречается 3-я форма нормализации - этого достаточно)
- уже очищены
- изменения задним числом недопустимы
Все это не про связи, это про правила жизни данных.

Тогда что включает в себя Data lake?

Озеро данных - это "склад без разборки"
Многие компании не знают, что пригодится завтра, поэтому максимально пытаются сохранить большее количество данных.
Данных действительно бывает много, не все они участвуют в бизнес-процессах и монетизируются. Но терять их никто не хочет.

Поэтому компании организовывают Озеро данных:
- данные хранятся как есть
- без очистки
- без структуры
- без гарантий
- связи между данными могут быть, а могут и нет

Но в некоторых данных встречала, что какие-либо отчеты формируются на данных из "озера".

Поэтому появляются термины, чтобы сказать:
- это БД, которая используется как DWH
- это БД, которая используется как Data Lake

В итоге, получается, что БД - это "где хранятся данные".
DWH и Data Lake - это как и в каком виде они там хранятся.

В моем канале На связи: SQL все простыми словами и с конкретными примерами.
Подписывайся!

или почему один запрос меняет данные, а другой — саму таблицу

Сегодня поговорим об изменениях.

В своем посте вот тут я уже писала об UPDATE

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

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

Базовый синтаксис:

UPDATE table_name

SET column = value

WHERE condition;

• SET — что именно меняем

• WHERE — какие строки

UPDATE:

• может блокировать строки

• работает внутри транзакции

• откатывается через ROLLBACK

Что же такое ALTER TABLE?

ALTER - это команда для изменения структуры таблицы:

• добавить столбец

• удалить столбец

• изменить тип данных

• переименовать столбец

По-простому:

ALTER — это «переделать бланк», а не вписать новые данные.

Базовый синтаксис:

ALTER TABLE table_name

ACTION;

Где ACTION — это то, что ты делаешь со структурой.

Самые частые варианты ALTER

➕ Добавить столбец

ALTER TABLE users

ADD COLUMN age INT;

✏️ Переименовать столбец

ALTER TABLE users

RENAME COLUMN name TO full_name;

🔄 Изменить тип данных

ALTER TABLE users

ALTER COLUMN age TYPE BIGINT;

❌ Удалить столбец

ALTER TABLE users

DROP COLUMN age;

Пример из жизни

Раньше ты не хранила возраст пользователей.
Потом бизнес сказал: «Нужно».

➡️ Это ALTER, потому что:

• раньше столбца не было

• данные тут ни при чём

Главное различие - в одной таблице:

В прошлый раз рассказывала про накопительную сумму.
Ссылка на пост вот тут.

Сегодня поговорим про скользящее окно.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков.
Разбор частых ошибок и задачи по накопительной сумме уже в канале.
Присоединяйся!

Running total ≠ Rolling window

Running total — накопительная сумма.
Это сумма всего, что было до текущего момента включительно.
Она никогда не уменьшается, если нет отрицательных значений.

Где используется

• общий доход с начала месяца / года

• накопленные регистрации

• рост базы пользователей

• прогресс выполнения плана

📌 Это метрика «накопления», а не «динамики»

Rolling window — скользящее окно

Rolling window считает сумму (или среднее) только за последние N дней / строк.

Старые данные выпадают из окна.

Какой вопрос она отвечает

Что происходит прямо сейчас, в последние N дней?

Пример запроса с использованием Rolling window в SQL

SELECT

date,

sales,

SUM(sales) OVER (

ORDER BY date

ROWS BETWEEN 6 PRECEDING AND CURRENT ROW

) AS rolling_7_days

FROM sales;

Самое важное для разбора - это строка
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW

В этой строке и появляется Rolling window

Разберём буквально:

ROWS
👉 окно считается по количеству строк, а не по датам

6 PRECEDING
👉 взять 6 строк до текущей

CURRENT ROW
👉 включить текущую строку

В итоге окно = 7 строк

6 предыдущих + текущая = 7 строк

Важно понимать:
📌 Не 7 дней.
📌 Не календарная неделя.
📌 А именно 7 строк в отсортированном наборе.
Сортировка идет по ORDER BY date

Когда использовать что

Running total, если:

• считаешь прогресс

• строишь cumulative-графики

• важно «сколько всего»

Rolling window, если:

• ищешь тренд

• сглаживаешь шум

• сравниваешь периоды

Ну а в моем канале На связи SQL тебя будут ждать задачи на скользящее окно. Кейсы с использованием ROWS и RANGE. Как сделать реальные 7 дней, а не 7 строк. Использование rolling-метрик в BI инструментах.
Подписывайся!

Есть цифры, которые сами по себе не информативны.
А есть цифры, которые показывают путь.

Накопительная сумма - это как раз про путь.

Обсудим сегодня эту тему.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

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

Если очень по-человечески:

Сегодня + вчера + позавчера + всё, что было раньше.

В SQL это часто называют:

• running total

• cumulative sum

Простой пример из жизни

Ты копишь деньги.

Сам по себе столбец «Отложила» — это просто факты.
А вот накопительная сумма отвечает на другой вопрос:

Сколько денег у меня есть к каждому дню?

Именно этот столбец обычно хотят видеть бизнес и пользователи.

Где применяется накопительная сумма

На практике — почти везде:

• 💰 финансы:
  доход, расходы, прибыль с начала месяца / года

• 📦 склад:
  остатки товаров

• 📊 аналитика продуктов:
  рост пользователей, регистраций, подписок

• 📈 KPI и планы:
  выполнение плана «на текущий момент»

• 🕰 временные ряды:
  динамика показателей во времени

Очень часто без накопительной суммы график просто не имеет смысла.

Как считается накопительная сумма в SQL

Современный и правильный способ — оконные функции.

Пример:

SELECT

date,

amount,

SUM(amount) OVER (ORDER BY date) AS running_total

FROM sales;

Что здесь происходит:

• SUM(amount) — считаем сумму

• OVER (...) — говорим: не по всей таблице сразу

• ORDER BY date — накапливаем по времени

Результат:

• первая строка → просто значение

• каждая следующая → сумма всех предыдущих + текущая

Если нужно накапливать отдельно (по группам)

Например, по каждому клиенту:

SUM(amount) OVER (

PARTITION BY customer_id

ORDER BY date

)

Теперь у каждого клиента своя накопительная сумма, и они не мешают друг другу.

Примеры задач и важные моменты с NULL публикую в своем канале На связи: SQL.
Подписывайся и изучай новую информацию