SQL *

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

SQL для аналитика: разбор 4 задач со скриптами и примерами данных

Собрала 4 задачи, которые решала на старте карьеры на реальных проектах, и показываю:
- как обычный GROUP BY превращается в полноценный ABC-анализ;
- как оконные функции помогают увидеть динамику, которую в Excel считать часами;
- как найти неэффективные категории (даже если по цифрам всё "нормально");
- как построить прогноз на паре оконных функций.

Внутри:
- Скрипты с пояснениями;
- Сгенерированные данные (можно скопировать и проверить);
- Пример бизнес-вывода к каждому запросу.

Статья для аналитиков, которые хотят прокачать SQL и понимать, что на самом деле происходит в их данных.

CJM в аналитике: почему ваши клиенты уходят и как это увидеть в данных

Вы наверняка видели красивые CJM-картинки с эмоциями, лицами и стрелочками, это красиво, но бесполезно, потому что настоящая карта пути клиента строится на данных, CJM – это не про «нарисовать портрет клиента», это про цифры, воронки и узкие места.

В этой статье я рассказываю:
- Что такое CJM с точки зрения данных (и почему это не про эмоции);
- SQL-скрипты для построения воронки, расчета времени между этапами и анализа переходов;
- Как искать узкие места, где клиенты реально страдают (и теряются деньги).

👉 Без абстракций, с кодом и готовыми данными для проверки.

Привет, Хабр! Это четвёртая статья из серии про QA собеседования. Уже разобрали тест-дизайн, API и Security и System Design. Теперь — SQL. На собеседованиях SQL задают чаще, чем многие ожидают. Не уровня DBA, но и не SELECT * FROM users. Обычно дают таблицу и просят написать запрос прямо на доске или в Google Docs. Если впадаете в ступор при слове JOIN — эта статья для вас.

Статья представляет компактную математическую нотацию для SQL-препроцессора, разработанную для формирования сложных условных выражений из JSON-конфигураций. Нотация позволяет кратко записывать операции с множествами и интервалами: комбинированные операторы (>=[18,65]), стрелочные символы для интервалов (>> — BETWEEN, >< — NOT BETWEEN) и логическое отрицание через знак минус. Цель — создать интуитивно понятный, непротиворечивый и расширяемый язык запросов. Практическое применение — генерация SQL-кода в препроцессорах, DSL для построителей запросов, компактные фильтры в JSON-API. Рассматриваются сильные стороны и потенциальные проблемы нотации, сравнительный анализ с аналогами (Quist, SQL++, PRQL), выявляется уникальность подхода. Автор приглашает к обсуждению и предлагает сотрудничество.

В статье разберем реальную задачу аналитика ассортимента в ритейле: «Какие товары люди покупают вместе», на учебных данных, с кодом SQL, со всей необходимой математикой и с примером выводов.

Когда я решила стать аналитиком, я не знала про SQL вообще ничего, совсем, базовое образование у меня экономическое и в университете SQL нам никто не преподавал.

В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.

Если вы пишете сложный SELECT, в котором одно и тоже вычисляется несколько раз, например, для массовой обработки данных пачками, то наверняка вам хотелось завести локальную переменную

вот пример:

SELECT
price * quantity AS total_price,
(price * quantity) * 0.15 AS tax,
((price * quantity) + ((price * quantity) * 0.15)) AS grand_total
...

Здесь price * quantity вычисляется несколько раз, и tax вычисляется дважды. Но это выглядит еще ок, в реальности это зачастую всякие монструозные свитч-кейсы с NULLIF, COALESCE и прочими ребятами.

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

Long story short, это делается так:

Все мы прекрасно знаем, join – одна из самых важных вещей в любой базе данных, но в то же время одна из самых ресурсозатратных операций. Да что уж там, в мире аналитики (OLAP) десятилетиями адепты различных подходов моделирования данных все спорят без остановки что лучше: нормализация (то есть много join) или денормализация (то есть мало join). Но все понимают, если можно без join, лучше без. Проблема в том, что они нужны практически всегда.

В этой статье давайте посмотрим, можно ли реально обойдись без join и в каких ситуациях? А также 4 способа, которые кратно ускорят ваши запросы.

Когда почта ложится — ложится всё. Переписка, задачи, согласования, доступы — всё завязано на почтовый сервер. А если под ним единственный PostgreSQL без резервирования, то между вами и катастрофой — один сбойный диск или зависший процесс.

В этой статье — пошаговый рецепт: собираем отказоустойчивый кластер PostgreSQL на базе Patroni, используем etcd для консенсуса и HAProxy как единую точку входа. Три виртуальные машины — и ваша почта RuPost переживёт падение ноды без потери писем и без ручного вмешательства.

Расскажу какие навыки потребуются, чтобы начать свой карьерный путь в качестве BI-аналитика, и поделюсь ресурсами, которые помогут прокачать эти навыки. Подборка из статьи будет полезна и начинающим специалистам, и профи - для увеличения кругозора.

Привет, Хабр!

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

Краткое содержание первой серии части (гиперссылка) нашего мануала:

мы развернули двухузловой кластер MySQL с асинхронной репликацией по GTID, улучшенной полу-синхронностью, и добавили два уровня отказоустойчивости: на уровне сервиса IP и роли БД.

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

📊 Хотите стать аналитиком данных, но не знаете, с какой стороны подойти?

Я собрала чек-лист для старта в 2026 году, никакой воды - только то, что реально спросят на собеседовании:
🛠 Что учить: SQL (с оконными функциями), Python (Pandas), BI-системы.
🧠 Важный софт-скилл, о котором молчат курсы — управление ожиданиями заказчика.
🔮 Бонус: что нужно знать про DWH и ML, чтобы выделяться среди других джунов.

Теперь Manticore Search поддерживает прямое указание настроек токенизации непосредственно в команде CREATE TABLE. Таким образом, исчезает необходимость создавать внешние файлы при настройке стоп-слов, исключений, словоформ и слов без позиции, делая создание таблиц проще и удобнее для развертывания.

Привет, сообществу Habr!

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

Наша команда Neoflex работает на проектах заказчика. При старте работ мы всегда подписываем NDA, но все равно этого недостаточно, чтобы владелец доверил нам полный доступ к промышленным данным. Мы его прекрасно понимаем: данные -  основа благополучия компании и видеть их должен ограниченный круг лиц, отвечающий за бизнес-результат.

Чтобы удовлетворить ожидания заказчика, выполнить вверенную нам работу и достичь высоких результатов при разработке функционала, нам нужны данные для тестирования, близкие к реальным. Тут возникает сложность – на тестовом контуре либо небольшой срез не консистентных промышленных данных, на которых нельзя протестировать полноценно функционал (например, витрину по операциям определенного сегмента клиентов с глубиной месяц, квартал), либо мы начинаем генерировать синтетику, не всегда попадая в нюансы вариативности данных, тратя на это дополнительные ресурсы.

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

Привет, Хабр! Важной составной частью Time Intelligence в DAX являются функции работы со временем, в частности, DATEADD, т.к. она является базовой для других (например, SAMEPERIODLASTYEAR является псевдонимом DATEADD('Date'[Date], -1, YEAR)) и возвращает таблицу (в отличие, например, от EDATE , которая возвращает только скаляр), и также может использоваться в качестве фильтра в CALCULATE.

Информацию о DATEADD приходится собирать из разных источников. Часть описано в официальной документации DATEADD, что-то есть в DAX Guide, что-то есть в материалах SQL BI, поэтому картина составляется по частям, хотя логика функции неочевидна и велики риски ошибок при использовании DATEADD в случае некорректного её использования.

Интересующимся правилами DATEADD для обеспечения Time Intelligence в DAX — добро пожаловать под кат :)

Сразу успокоим читателя: AI не вытеснил data-инженера из рабочего процесса. Наоборот, он сделал эту роль еще более значимой. И в этой статье объясняется, что именно это означает для вас и вашей профессии. Не с точки зрения технологий и инструментов, а с точки зрения изменения зоны ответственности.

AI, как и везде, конечно классно справляется с некоторыми задачами, но всю ответственность по-прежнему несет человек. Весь контекст не передашь через промпт, и AI не делает компромиссных решений. Большинство систем не выходят из строя, потому что было сложно написать код. Выходят потому что решения по разработке были приняты поспешно, и без четкого понимания, кто и как этими системами будет пользоваться. И AI еще быстрее за нас принимает решения, но все те же риски «непонимания контекста» остаются.

Кажется, что в ИТ всё меняется каждые пару лет. Фреймворки рождаются и умирают, архитектурные подходы сменяют друг друга, но SQL стабильно остается на месте. Он спокойно пережил хайп вокруг NoSQL, эпоху Big Data и повсеместное внедрение нейросетей.

Сегодня SQL давно перестал быть узким «языком админов». Это универсальный стандарт общения с данными, который жизненно необходим бэкендерам, аналитикам, QA-инженерам и даже продакт-менеджерам.

В этой статье мы пропустим скучную академическую теорию и разберем только то, что реально нужно в работе. Мы пройдем путь от анатомии таблиц и базовых джоинов до оконных функций. А в конце заглянем под капот базы данных и разберем логический порядок выполнения запроса — секретный ингредиент, который навсегда избавит вас от вопроса: «Почему эта строчка не работает?!».

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

По этой причине данная статья может оказаться полезной не только новичкам, но и тем, кто уже использует T-SQL в своей работе.

Документация явно описывает два типа констант: обычные строковые и юникодные. Но на самом деле ситуация несколько сложнее, что и будет рассмотрено ниже.

В данной статье я покажу код на JS, который не поместился в предыдущей статье, а также перепишу его на TS. Кратко расскажу о преимуществах TS над JS и о том, что необходимо понимать для перехода.

В прошлой статье я также упоминал, что у Сергея получилось запустить мой проект на Tauri в режиме разработки на Arch. Он поделился со мной информацией в issue на GitHub и тем самым внёс вклад в проект. Поэтому я решил попробовать исправить проблему на основе его issue. Заодно расскажу, что такое issue и как оно выглядит.

Заваривайте чай, доставайте вкусняшки — пора «снимать первый урожай помидор»! 🍅