PostgreSQL и Oracle для аналитка
Я недавно вышла в найм.
И попала в реальность, где компании активно импортозамещаются, переписывают монолиты, режут их на микросервисы…
Но историческая база при этом — на Oracle Database.
И если ты много лет работал с PostgreSQL, переключение ощущается не как «ну ладно, другая СУБД»,
а как смена диалекта с тем же словарём, но другой грамматикой.
Важно: это взгляд аналитика.
Не администратора.
Не архитектора.
А человека, который каждый день пишет SELECT.
1️⃣ Работа с NULL
В PostgreSQL
COALESCE(value, 0)
Работает как и в большинстве СУБД.
В Oracle
NVL(value, 0)
Да, COALESCE тоже работает.
Но в легаси-коде ты почти везде увидишь NVL.
Для аналитика это значит:
читаешь чужой код - будь готов к другому синтаксису.
2️⃣ Ограничение строк (LIMIT)
PostgreSQL
SELECT *
FROM table
LIMIT 10;
Oracle
В старых версиях:
SELECT *
FROM table
WHERE ROWNUM <= 10;
В новых версиях:
FETCH FIRST 10 ROWS ONLY
3️⃣ Работа с датами
Вот здесь начинаются настоящие нюансы.
PostgreSQL
Очень удобные конструкции:
CURRENT_DATE
NOW()
DATE_TRUNC('month', date_column)
AGE()
Интервалы читаются логично:
date_column + INTERVAL '1 month'
Oracle
SYSDATE
TRUNC(date_column, 'MM')
ADD_MONTHS(date_column, 1)
4️⃣ Работа со строками
PostgreSQL:
STRING_AGG(column, ',')
Oracle:
LISTAGG(column, ',') WITHIN GROUP (ORDER BY ...)
Синтаксис разный, логика похожая.
А в моем канале Аналитика FM выпуски про расчет Retention в разных бизнесах.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!
Онбординг. Как и что...
Онбординг - это систематический процесс адаптации нового сотрудника в компании.
В это период решается - человек станет частью системы или останется внешним наблюдателем.
Из здесь всегда есть две стороны:
что важно новичку
что важно работодателю
И они не всегда совпадают.
А в моем канале Аналитика FM выпуски про расчет Retention в разных бизнесах.
Канал я веду с нуля подписчиков, рассказываю про аналитику и разбираю различные кейсы на реальных примерах.
Подписывайся, если интересно как устроен мир аналитика!
Что важно новичку
Новичку в первые недели нужно не "вдохновение", а опора.
Ему важно:
понимать, что считается хорошей работой
понимать, по каким правилам принимаются решения
знать, куда можно задавать вопросы
понимать, что можно ошибаться
Самая частая тревога новичка:
Я не понимаю, правильно ли я делаю.
Если этой ясности нет - человек начинает тратить энергию не на работу, а на догадки.
Что важно работодателю
Работодателю важно другое:
чтобы сотрудник быстрее начал приносить результат
чтобы не отвлекать команду постоянными вопросами
чтобы человек стал самостоятельным
И здесь возникает классический конфликт:
Нужно ли подробно объяснять всё,
или лучше рассказать в общих чертах и “плыви сам”?
Две крайности
1. Гиперопека
Когда новичку:
всё разжёвывают
дают пошаговые инструкции
контролируют каждый шаг
Минус:
человек не учится думать самостоятельно.
Он становится зависимым от системы.
2. "Разбирайся сам"
Когда говорят:
Вот документация
Вот коллеги
У нас всё описано
Минус:
новичок не понимает негласные правила.
А в любой компании именно они самые важные.
Баланс
Хороший онбординг - это не лекция и не квест.
Это:
объяснение принципов
показ реальных кейсов
и постепенное усложнение задач
Важно объяснить:
как устроена логика компании
какие решения типичны
какие ошибки критичны
А дальше - да, человек должен идти и разговаривать с коллегами.
Потому что адаптация - это не только получение знаний.
Это встраивание в живую систему.
Пример условного Google
Представим офис Google. Там множество отделов, направлений, команд, людей.
И сделать программу ондординга, подходящую под каждый отдел/направление - мне кажется нереально. Поддерживать и адаптировать внедренную политику онбординга каждому отделу самостоятельно - тоже видится, что приведет к хаосу.
При зачислении на работу, сотрудникам не проводят инструктаж. В общих чертах вводят в курс, а дальше: иди общайся с коллегами, сам узнавай, как тут все устроено и как тебе эффективнее решить задачу.
Уметь общаться, объяснять и договариваться - базовый минимум для всех в компании. Этот навык здесь как фильтр.
А я до сих пор не понимаю (ну или не принимаю) - почему новичку надо преодолевать все эти круги ада, у него и так стресс - он пришел туда, где ему мало что известно именно про внутренние процессы и "обычаи". Да, он может знать о компании из внешних источников, да, он может знать концепцию бизнеса (и то, опираясь на свой опыт), но он явно не знает как и что устроено именно в этой конкретной компании.
Для такой компании важно:
чтобы сотрудник умел задавать вопросы
чтобы он спорил аргументированно
чтобы он предлагал решения
чтобы он был автономным
Если новичка в такой среде постоянно "ведут за руку" -
он не впишется в культуру.
Но и бросать его в хаос нельзя.
Поэтому в сильных компаниях:
есть чёткие процессы - иногда из четких процессов: Иди и разберись сам
есть наставник - иногда... Документация твой наставник
есть культура обратной связи - О боже, она бывает культурной...
Но при этом от человека ждут роста.
Вот тут важная аналогия
Когда-то динозавры были самыми крупными и доминирующими существами на планете.
Но они не смогли адаптироваться к изменениям среды -
и вымерли.
Размер, сила и масштаб не гарантируют выживания.
Гарантирует только способность адаптироваться.
Онбординг - это первая проверка на адаптацию.
Для сотрудника:
готов ли он учиться
готов ли он задавать вопросы
готов ли он менять привычные способы работы
Для компании:
готова ли она объяснять
готова ли она слышать нового человека
готова ли она меняться вместе с ним
Онбординг — это не про количество информации.
Это про скорость понимания среды.
Новичку важно дать:
ориентиры
ценности
границы
Но дальше он должен расти сам.
Потому что в долгосрочной перспективе
выживают не самые крупные компании
и не самые опытные сотрудники.
Выживают те,
кто умеет адаптироваться.
В канале Аналитика FM рассказываю про аналитику, SQL и аналитическое мышление.
Про особенности работы с данными.
Ну и пост о моем текущем опыте онбординга в новую компанию уже на подходе.
В новой компании я почти месяц уже!
Подписывайся!
Прокачал свой тренажер SQL: новый дизайн, структурированные уроки и всё даром!
Привет, Пикабу!
Хочу поделиться обновлением своего пет-проекта, над которым работаю в свободное время — sqltest.online. Это бесплатный онлайн-тренажер для тех, кто хочет набивать руку в написании SQL-запросов прямо в браузере, не заморачиваясь с установкой тяжелых баз данных.
Что изменилось в этом обновлении?
Полный редизайн. Старый интерфейс был «суровым» и чисто функциональным. Теперь всё стало чище, удобнее и современнее. Я переработал рабочую область, чтобы ничего не отвлекало от кода, а результаты запросов читались с первого взгляда.
Новая система уроков. Если раньше это была просто «песочница» со списком задач, то теперь я добавил структурированные уроки. Теперь это полноценный путь: вы идете от самых основ (простые выборки) к более сложным темам (группировки, джойны, вложенные запросы) в логичном порядке.
Почему это удобно?
Всё в браузере: Не нужно разворачивать PostgreSQL или MariaDB локально. Зашел, написал код, увидел результат.
Бесплатно и доступно: Делаю проект для души, поэтому никакой регистрации, подтверждений почты или платных подписок.
Поддержка языков: Интерфейс полностью на русском.
Зачем я это пишу? Проект живет и развивается на моем энтузиазме. Мне очень важен ваш фидбек: удобно ли пользоваться новым интерфейсом? Хватает ли пояснений в новых уроках? Любая критика или идеи по новым задачам — это лучший стимул фиксить баги и пилить новый контент.
Если вы сейчас учите SQL или просто хотите освежить навыки перед собеседованием — залетайте тестировать.
Ссылка на проект: sqltest.online
Буду рад пообщаться в комментариях!
Первое знакомство с новой Базой Данных
Ты открываешь схему.
Сотни таблиц.
Описание есть — понимания нет.
Коллеги заняты. Онбординга "с объяснениями на пальцах" не будет.
И ты остаёшься один на один с данными.
Обычно начинают с просмотра таблиц руками:
что в них лежит,
какие поля реально заполнены,
какие значения встречаются,
какие даты живые, а какие "мертвые".
Ошибка, которую делают новички
Когда нет понимания структуры, новички часто:
сразу пишут "большой правильный запрос",
делают несколько JOIN подряд,
не проверяют объёмы данных,
не смотрят кардинальность,
а потом говорят: "База тормозит".
Но чаще всего тормозит не база.
Тормозит наше понимание модели данных.
Для начала, важно понять логику. Таблицы - это реализация, а нам надо понять:
что является сущностью,
что является атрибутом,
что является справочником,
где факт, а где классификатор.
Затем, не надо делать сразу финальный запрос, который должен вернуть результат со сложной логикой:
Сначала:
SELECT COUNT(*)
LIMIT 100
группировки по статусам
проверка на NULL
проверка дублей
Каждый JOIN нужно проверять отдельно:
сколько строк было до соединения,
сколько стало после,
не раздули ли вы данные в 10 раз.
Это экономит часы.
Самый важный вопрос:
по чему соединяются таблицы?
это 1:1, 1:N или N:N?
есть ли составные ключи?
Очень часто "медленный запрос" - это не индексы и не сервер,
а просто не тот ключ в JOIN.
Если запрос со сложной логикой и при запуске висит - не нужно грешить на "неповоротливость базы "
Нужно спросить:
есть ли индексы на поля соединения?
используется ли фильтрация до JOIN?
не делаем ли мы unnecessary full scan?
База редко "плохая".
Она просто делает ровно то, что ты ей сказал.
Важно искать живые примеры:
Очень правильный шаг — смотреть запросы коллег.
Это даёт:
понимание договорённостей,
понимание "какие данные считаются валидными",
понимание негласных ограничений.
Иногда реальная логика живёт не в описании таблиц,
а в том, какие фильтры люди используют годами.
Знакомство с новой БД — это не проверка твоего SQL.
Это проверка твоего мышления.
Новичку важно понять:
база не обязана быть удобной
справочники не обязаны быть очевидными
описание не равно пониманию
И если запрос выполняется час —
в 80% случаев проблема не в сервере,
а в отсутствии структуры в голове.
Для новичка не стоит пытаться доказать, что ты умеешь писать сложные запросы.
Попробуй сначала понять:
что здесь является "фактом",
что "состоянием",
что "справочником",
и что вообще считается "актуальной записью".
Когда появляется понимание модели —
запросы начинают работать быстрее.
И технически, и логически.
Потому что быстрая БД начинается
не с индексов,
а с правильных вопросов.
В моем канале Аналитика FM все про мышление аналитика, про инструменты аналитика.
Мы рассматриваем SQL и Python в применении к данным.Этот канал я веду с нуля подписчиков. Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!
Психотерапевт для бизнеса
Недавно я получила комментарий к одному из моих постов, что "хороший аналитик" - это как психотерапевт для бизнеса!
Я полностью согласна с этим!
Психотерапия - это курс регулярных встреч, на которых врач с помощью специальных техник помогает пациенту понять причины его состояния, изменить деструктивные модели мышления и поведения, научиться справляться с трудностями и реагировать на стресс, а также развить навыки эмоциональной саморегуляции.
Так описывается взаимодействия "человек-человек". Но и для бизнеса тоже есть свои психотерапевты. Очень часто эту роль выполняет аналитик. Иногда в связке с финансистом или продактом. Именно аналитик задает правильные вопросы и переводит ощущения в факты.
В моем канале Аналитика FM я рассказываю про инструменты аналитика, про мышление и разбираю рабочий кейсы. Мы рассматриваем SQL и Python в применении к данным.
Этот канал я веду с нуля подписчиков.Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!
Бизнес, как и человек, редко приходит с чётким запросом.
Обычно это звучит так:
Продажи что-то просели
Маркетинг стал дорогим
Клиенты какие-то не такие
Кажется, мы зарабатываем, но денег нет
Это не диагноз. Это эмоции и тревога.
Бизнес чувствует, что всё плохо.
Аналитик проверяет:
где именно плохо,
с какого момента,
для каких сегментов,
и плохо ли вообще.
Иногда оказывается, что:
revenue растёт,
но падает маржа,
или растёт LTV, но сжирается CAC,
или прибыль есть, но кэшфлоу убит.
Аналитик возвращает контроль через структуру.
Пока нет цифр - есть хаос.
Появляются метрики → появляется язык, на котором бизнес может с собой разговаривать.
Аналитик:
договаривается, что считать,
как считать,
и зачем.
Это ровно как в терапии: сначала выстраивается общий словарь.
Аналитик помогает увидеть причинно-следственные связи.
Бизнес часто путает:
симптомы и причины,
решения и их последствия.
Аналитик показывает:
какие действия к чему привели,
где решение помогло, а где замаскировало проблему,
и что будет, если ничего не менять.
Не "плохо работает маркетинг",
а "вот где именно он перестал окупаться и почему".
Хороший аналитик не обвиняет.
Он говорит:
Это не ошибка команды
Это ограничение модели
Это следствие выбранной стратегии
Как психотерапевт - без осуждения, но честно.
Аналитик не решает за бизнес,
но делает так, чтобы решения принимались не на тревоге, а на понимании.
Аналитик - не спасатель и не волшебник.
Он не делает бизнес успешным.
Он делает бизнес осознанным.
А дальше - как в жизни:
осознанность не гарантирует счастья,
но резко повышает шансы перестать делать себе больно.
Поэтому, если отвечать на вопрос коротко:
психотерапевт для бизнеса - это аналитик, который умеет слушать цифры и переводить их на человеческий язык.
В моем канале Аналитика FM уже вышла серия постов про Revenue в разных бизнесах.
Как рассчитывается, где и какие есть особенности. Как пишутся запросы на SQL.Если тоже хочешь разобраться в нюансах подсчета выручки в разных бизнесах, то подписывайся.
Следующая серия постов будет про Retention.
Revenue в разных бизнес кейсах и как его считать
Revenue часто переводят как "выручка" - и на этом понимание заканчивается.
Кажется логичным: если деньги пришли на счёт, значит бизнес заработал.
Но в реальности Revenue - это доход, который бизнес признал, а не просто получил.
Ключевое слово здесь - признал.
То есть ответ на вопрос не "когда заплатили", а когда бизнес считает, что он действительно заработал эти деньги.
И вот тут начинаются нюансы.
Кстати, в моём канале Аналитика FM уже есть примеры SQL-запросов для расчёта Revenue в разных бизнес-моделях. Ниже как раз объяснение, почему этих вариантов так много.
Присоединяйся!
В классическом виде Revenue:
Revenue = количество × цена
Или:
сумма чеков
сумма оплаченных заказов
сумма выставленных счетов
Это работает ровно до тех пор, пока бизнес простой.
Но как только появляются:
подписки
рассрочки
комиссии
возвраты
отложенные услуги
формула "сумма денег" перестаёт отражать реальность.
Пример: клиент оплатил год обучения сразу.
Но по договору он может расторгнуть его и вернуть часть денег.
Если считать Revenue как "всё, что оплатили", то при возврате показатели будут прыгать - и бизнес будет принимать решения на искажённой картине.
Как по-разному считается Revenue в разных бизнесах
1️⃣ Транзакционные офлайн-бизнесы
(кафе, рестораны, услуги)
Здесь всё относительно честно и просто:
Revenue = сумма оплаченных чеков
возвраты не входят
дата Revenue = дата покупки
Заплатили → заработали.
2️⃣ Подписочные и онлайн-продукты
(SaaS, онлайн-образование)
Здесь деньги и доход - разные сущности.
деньги могут прийти сразу
Revenue признаётся равномерно во времени
payment ≠ revenue
Если подписка действует 3 месяца, то и доход "размазывается" по этим 3 месяцам - независимо от того, когда пришла оплата.
Поэтому:
смотрят не на платёж
считают строго по периоду оказания услуги
На практике для этого делают отдельную таблицу начислений, а не пересчитывают всё каждый раз.
3️⃣ Финансы и страхование
В финтехе деньги почти никогда не означают доход «сегодня».
кредит выдали сегодня
доход зарабатывается постепенно
Revenue считается на даты начислений
Причём Revenue может:
пересчитываться задним числом
меняться из-за досрочного погашения
корректироваться из-за каникул, судов, ошибок
Здесь Revenue отвечает на вопрос:
"Когда мы реально заработали?",
а не "когда приняли решение выдать кредит".
4️⃣ Розница и FMCG
Фокус не на клиенте, а на товаре.
Revenue = количество × цена
считается по SKU, магазинам, регионам
аналитика чаще товарная, чем клиентская
Кто купил - вторично. Главное - что и где продали.
5️⃣ Маркетплейсы и платформы
Самый частый источник ошибок.
Клиент платит много, но:
эти деньги не принадлежат платформе
платформа - посредник
Поэтому:
order_amount ≠ revenue
Revenue = комиссия + сервисные сборы
Платформа не владеет товаром и не несёт товарные риски.
Она зарабатывает на услуге, а не на продаже.
6️⃣ Проектные и экспертные бизнесы
Здесь нет логики "продал → отгрузил → забыл".
Работа делается этапами.
Каждый этап:
закрыт
принят заказчиком
имеет согласованную стоимость
Revenue признаётся по факту выполненной работы, а не по оплате.
Это не прихоть аналитиков, а:
бухгалтерский принцип
управленческий принцип
часто юридическое требование
Главное, что важно запомнить
Revenue — это всегда:
про модель бизнеса
про правила признания
про момент, когда бизнес считает, что заработал
Одна и та же формула в разных компаниях может означать совершенно разные вещи.
И именно поэтому нельзя просто взять "SUM(amount)" и успокоиться.
Если хочешь посмотреть, как это выглядит в реальных SQL-запросах -
в канале Аналитика FM я уже разбираю расчёт Revenue для разных бизнесов:
подписки, финансы, маркетплейсы и проектные модели.
Без магии - только логика и данные.Подписывайся!
Новичок аналитик в 2026 году
Стоит ли вообще идти в аналитику в 2026 году, если раньше ты в этом совсем не разбирался.
Если коротко и честно, то стать аналитиком в 2026 году можно, но это больше не "вход через открытую дверь", как было несколько лет назад.
Эпоха "пройду курс → получу оффер" закончилась.
И это не трагедия - это просто взросление рынка.
Рынок больше не испытывает дефицита новичков.
Зато он испытывает дефицит людей, которые:
понимают, зачем считают цифры
умеют думать, а не только писать запрос
могут связать данные с реальным решением
Компаний не стало меньше.
Просто они перестали нанимать работников "впрок".
Главный миф, который мешает новичкам
Нужно выучить SQL / Python / BI - и меня возьмут
По факту - нет.
Инструменты аналитика - это минимальный входной билет, а не профессия.
Аналитика сейчас не просто про написание SELECT, построить дашборд, посчитать метрику.
Сейчас аналитику необходимо понять, какой вопрос вообще имеет смысл задавать.
Проверять или знать, что данные действительно отвечают на этот вопрос.
Полученный результат объяснять так, чтобы по нему могли действовать.
Для новичка необходимо знать следующее:
- базовая логика данных: строка, таблица, срез, период, агрегация
- почему данные могут быть неполными, кривыми и противоречивыми и что с этим делать
- воспринимать SQL как язык мышления, а не просто синтаксис, а понимать что делает JOIN с данными; почему GROUP BY может "сломать смысл", почему NUL - это не 0 и не "пусто"
Об этом и о многом другом я рассказываю в своем канале Аналитика FM.
Его я веду с нуля подписчиков. В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках. Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!
- необходимо понимать контекст бизнеса: откуда берутся деньги, что считается успехом, какие решения вообще принимаются.
Для новичка не надо целится сразу в "классического аналитика".
Реалистичными точками входа будут:
аналитик внутри операционных команд
продуктовые команды с простыми метриками
поддержка, финансы, логистика, маркетинг
смежные роли, где аналитика - часть работы, а не вся роль
Часто аналитиками становятся изнутри, а не "с улицы".
Что делать, если опыта нет вообще
Не пытаться выглядеть "готовым специалистом".
Это видно сразу и не работает.
Работает другое:
разбор реальных кейсов
умение объяснить ход мыслей
честное "я не знаю, но вот как бы я проверил"
В 2026 ценится не уверенность, а адекватность мышления.
А стоит ли вообще сейчас идти в аналитику?
Самый важный вопрос.
Если мотивация:
«хочу в IT»
«хочу удалёнку»
«говорят, там платят»
- скорее нет.
Если мотивация:
нравится разбираться
задавать вопросы
сомневаться в очевидном
искать смысл за цифрами
- да, время нормальное.
Аналитика никуда не исчезнет. Просто она больше не про "быстро войти", а про долго остаться.
Главное, что стоит понять новичку в 2026
Аналитик - это не профессия "на хайпе".
Это роль для тех, кто готов:
не знать ответ сразу
задавать неудобные вопросы
сомневаться в цифрах
и брать ответственность за выводы
Если хочешь, в Аналитика FM я как раз пишу про это:
не как "стать аналитиком", а как не потеряться в данных и ожиданиях,
и почему SQL - это не про код, а про мышление.
Сейчас как раз выходит серия постов про Revenue в разных бизнесах.
Присоединяйся!





