Привет всем! Давно не виделись — у меня был большой перерыв, но я возвращаюсь и рад снова делиться с вами полезными и интересными материалами. За это время было много новых идей и опыта, которыми хочу с вами поделиться, а также поделиться о своем новом проекте, который надеюсь совсем скоро будет запущен, и в котором каждый сможет принять участие. Спасибо, что остаетесь на связи, ваши поддержка и интерес для меня очень важны! Скоро начнется новый виток полезного контента, оставайтесь с нами!

LEFT JOIN кажется простым: «возьми всё из левой таблицы и добавь, что найдётся справа».
Но на деле — это один из самых коварных операторов SQL 😈

⚠️ 1. COUNT(*) считает лишнее

После LEFT JOIN даже записи без совпадений получают строку с NULL.
COUNT(*) считает и их — поэтому результат оказывается завышенным.

➡️ Решение:
используй COUNT(правая_таблица.id), чтобы считать только реальные совпадения.

❌ 2. Условия в WHERE ломают LEFT JOIN

Добавил фильтр в WHERE, например:
WHERE orders.status = 'active'

И всё — твой LEFT JOIN превратился в INNER JOIN.
Пользователи без заказов пропали из результата.

➡️ Решение:
перенеси фильтр в ON:

LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'active'

🕵️‍♂️ 3. NULL — не всегда «ничего»

После LEFT JOIN поля из правой таблицы могут стать NULL.
Если потом сравниваешь =, !=, или фильтруешь WHERE column IS NOT NULL — результат может быть неожиданным.

➡️ Решение:
используй COALESCE() или явно проверяй IS NULL / IS NOT NULL.

⚙️ 4. LEFT JOIN трёх и более таблиц

Когда соединяешь несколько таблиц подряд можно легко потерять контроль, по какой именно таблице ты делаешь подсчёт.

Например, COUNT(payments.id) будет считать только оплаченные заказы, а COUNT(orders.id) — всех, у кого вообще есть заказы.

➡️ Решение:
будь внимателен при группировке — всегда считай по нужной таблице
и чётко понимай, на каком уровне детализации формируется результат.

Далее подробно будем разбирать каждый из моментов.

Сегодня, у нас небольшое пополнение. Ребята из группы решили присоединиться. Спасибо. В этой группе скоро станет невероятно интересно, пока вы даже не понимаете насколько.

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

Хотите еще новость. Сегодня я сдал высший уровень владения PostgreSQL.

5 лет назад я даже не понимал для чего нужен SQL.

По просьбе ребят, подготовил краткую шпаргалку.

🧭 Как не забыть SQL после курса ?

1. Практикуйся каждый день

SQL — это навык, который держится на регулярности.
10–20 минут в день уже дают результат.
Используй тренажёры, например:

SQLZoo
LeetCode SQL
Hackerrank SQL

2. Повторяй материал курса

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

3. Веди “SQL-дневник”

После каждой практики запиши коротко:
Что повторил или узнал
Что вызвало трудности
Один полезный приём или запрос

Так создашь личную базу знаний и мотивации.

4. Повторяй темы циклично

Раз в неделю пробегай ключевые блоки:
SELECT → JOIN → GROUP BY → подзапросы → оконные функции
Постоянное повторение — основа уверенности.

5. Применяй SQL в жизни

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

Регулярность важнее длительности. Главное — не прекращать.

💬 Стоит ли использовать ИИ в работе и обучении?

Меня часто спрашивают:
можно ли вообще использовать ИИ для работы или обучения?

Отвечаю — можно и нужно.
Но важно — делать это с головой.

ИИ реально помогает: ускоряет задачи, подкидывает идеи, помогает учиться.
Но есть нюанс — он не несёт ответственности.
Ошибся не ИИ, а ты. Спрашивать будут с нас.

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

ИИ — не костыль. Это инструмент для роста.
Он может помочь понять больше, но не подменяет мышление.
И чем лучше ты сам разбираешься в теме, тем сильнее эффект от его использования.

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

Поэтому ИИ не должен «разучивать» нас — наоборот, он должен мотивировать учиться ещё больше, чтобы использовать его максимально эффективно.

ИИ — не замена эксперту.
Он — ускоритель эксперта 🚀

🎓 7 строковых функций в PostgreSQL, которые стоит знать каждому аналитику.

🔹 1. LOWER / UPPER — меняют регистр текста

Используются, чтобы привести строки к одному формату перед сравнением.

SELECT
LOWER('PostgreSQL'), -- postgresql
UPPER('sql rocks'); -- SQL ROCKS

🔹 2. CONCAT и || — объединяют строки

Но будь внимателен ⚠️: CONCAT() игнорирует NULL,
а || вернёт NULL, если хотя бы один аргумент NULL.

SELECT
CONCAT('Ivan', ' ', 'Petrov'), -- Ivan Petrov
CONCAT('Ivan', ' ', NULL), -- Ivan
'Ivan' || ' ' || 'Petrov', -- Ivan Petrov
'Ivan' || ' ' || NULL; -- NULL ⚠️

🔹 3. SPLIT_PART — разделяет строку по разделителю

Укажи строку, символ-разделитель и номер части, которую хочешь получить.

SELECT
SPLIT_PART('ivan.petrov@example.com', '@', 1), -- ivan.petrov
SPLIT_PART('ivan.petrov@example.com', '@', 2); -- example.com

🔹 4. SUBSTRING — достаёт часть строки

Работает по позиции и длине: “начало” и “сколько символов”.

SELECT
SUBSTRING('2025-10-21' FROM 1 FOR 4), -- 2025
SUBSTRING('Analytics' FROM 4 FOR 3); -- lyt

🔹 5. LEFT — возвращает первые n символов

Когда нужно взять только начало строки.

SELECT
LEFT('PostgreSQL', 4); -- Post

🔹 6. RIGHT — возвращает последние n символов

Помогает достать “хвост” строки — например, окончание кода или номера.

SELECT
RIGHT('PostgreSQL', 3); -- SQL

🎯 SQL-фишка дня: подзапрос в WHERE

Иногда нужно выбрать строки на основе данных из другой таблицы. В таких случаях выручает подзапрос в выражении WHERE👇

🔹 Пример с IN

SELECT *
FROM orders
WHERE customer_id IN (
                      SELECT id 
                      FROM customers
                      WHERE country = 'Germany'
                      );

🧠 Что происходит:
— внутренний подзапрос возвращает всех клиентов из Германии
— внешний выбирает все заказы этих клиентов, сравнивая поле customer_id внешнего запроса с полем id подзапроса

🔹 А теперь наоборот — NOT IN

SELECT *
FROM orders
WHERE customer_id NOT IN (
                          SELECT id 
                          FROM customers
                          WHERE country = 'Germany'
                          );

💡 Здесь мы получим все заказы клиентов, которые НЕ из Германии.

🎯 Мультимодельные базы данных — когда одной модели уже мало

Традиционно системы управления базами данных строились вокруг одной модели данных:

реляционной (таблицы),

документной (JSON),

графовой (узлы и связи).

Теперь всё чаще появляются решения, которые объединяют несколько моделей в одной СУБД.
Такой подход позволяет хранить и обрабатывать разные типы данных — таблицы, документы, графовые структуры — в едином движке, без необходимости интегрировать разные системы.

Это упрощает администрирование, ускоряет аналитику и снижает сложность архитектуры.
Некоторые традиционные реляционные СУБД тоже движутся в этом направлении, добавляя поддержку JSON, графов и других структур данных.

Примеры мультимодельных СУБД: ArangoDB, OrientDB, Couchbase.

☕️ SQL — как заказать кофе

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

Он декларативный: ты формулируешь результат,
а база данных сама решает, как его достичь.

Если бы ты заказывал кофе в стиле SQL 👇

SELECT coffee — что заказать
FROM coffee_shop — где заказать
WHERE sugar = false — без сахара
AND payer = 'Петя' — а платит Петя :)
GROUP BY friend; — каждому по кофе

Ты не говоришь бариста, как молоть зёрна или варить кофе.
Ты просто декларируешь результат:

«Хочу кофе без сахара, за счёт Пети, как обычно у нас в компании».

SQL — язык ясных намерений и доверия к исполнителю.
База данных, как идеальный бариста, сделает всё сама ☕️

💼 5 навыков, кроме SQL, которые сегодня ищут работодатели

Российский рынок труда переживает кадровый дефицит:
безработица в октябре 2025 года составляет всего 2–3 % — исторический минимум. Компании конкурируют за специалистов, особенно в IT, инженерии и аналитике.

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

🔹 1. Python и автоматизация анализа данных

Python стал стандартом для аналитиков в России —
почти половина вакансий включает его в обязательные навыки.
Также востребованы R, pandas, NumPy и библиотеки машинного обучения.

🔹 2. BI-инструменты (Power BI, Yandex DataLens, Tableau)

Бизнес активно переходит на визуальную аналитику.
Особенно растёт популярность Yandex DataLens — за счёт локализации и интеграции с экосистемами Яндекса.

🔹 3. Бизнес-анализ и постановка задач

Аналитиков всё чаще нанимают на стыке бизнеса и IT.
Важно уметь понимать метрики, воронки продаж, ROI и продуктовые цели.

🔹 4. Визуализация и сторителлинг с данными

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

🔹 5. Мягкие навыки (soft skills)

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

💬 Итог: чтобы быть востребованным аналитиком в 2025 году,
нужно сочетать инструменты, логику и умение объяснять данные людям.

⚙️ Функция COALESCE — простая подстановка значений в SQL

Когда в таблице встречаются NULL, логика запросов ломается.
Функция COALESCE помогает “подставить” значение по умолчанию, если значения отсутствуют, то есть вместо них NULL.

🔹 Как работает

SELECT COALESCE (NULL, 'default'); -- вернёт 'default'
SELECT COALESCE ('данные', 'default'); -- вернёт 'данные'

COALESCE просто берёт первое не-NULL значение из списка аргументов.

🔹 Пример:

SELECT name,
       COALESCE (phone, '— нет телефона —') AS phone_display
FROM clients;

Если в поле phone встретятся значения NULL, то вместо них выведется фраза: — нет телефона —.

🔹 Несколько значений:

SELECT COALESCE(email, backup_email, '— нет контактов —') AS contact
FROM users;

Здесь функция проверяет значения полей, заданных в скобках по порядку: email → backup_email → '— нет контактов —'.

🧠
COALESCE — это страховка от NULL,
и её можно использовать почти везде: в SELECT, ORDER BY, GROUP BY, даже в UPDATE.
Вообщем это очень крутая функция, знать о которой обязательно.

🧨 Почему SELECT * — это зло, и PostgreSQL тебе этого не простит ?

Когда ты пишешь SELECT *, где-то внутри PostgreSQL тихо плачет планировщик 😢 Потому что вместо одного красивого запроса ты запускаешь комбайн по растаскиванию кучи строк.

Вот почему:

1️⃣ Хеш-таблица при алгоритме соединения Hash Join пухнет до параметра work_mem (параметр, выделяющий память для обработки запросов).

Если ты делаешь JOIN, Postgres может выбрать алгоритм соединения Hash Join, как один из алгоритмов и хеш таблица будет построена по всем выбранным колонкам.
Когда ты ставишь *, туда летит всё подряд.
Результат — work_mem забит, планировщик начинает спиллинг на диск, и “быстрый” JOIN идёт пить кофе ☕️

2️⃣ TOAST говорит: “Приятного аппетита!”

Postgres хранит длинные значения (TEXT, JSONB и т.д.) в TOAST-таблицах. TOAST - это такая специальная технология для хранения больших значений в отдельных таблицах.
Если ты выбираешь *, он вытаскивает их в любом случае, даже если тебе нужно только id. То есть ты сам зовёшь на ужин все 10-гигабайтные тексты, которые никто не ел 🤦‍♂️

3️⃣ INDEX ONLY SCAN? Нет, не слышали.

INDEX ONLY SCAN - оптимизация при которой нужные в результате столбцы есть в самом индексе. То есть возможно не нужно обращаться к самой таблице, а достать все данные из самого индекса, работает очень быстро и эффективно.
Но SELECT * ломает эту оптимизацию — Postgres вынужден идти в heap (кучу строк), чтобы достать остальные поля.
И твой быстрый запрос превращается в медленный.

4️⃣ Лишние данные = лишняя нагрузка

Сеть, CPU, память — всё страдает.
Даже если приложение потом использует 2 поля из 20, Postgres всё равно тащит весь мешок данных и заботливо складывает тебе в ответ.

5️⃣ Буферный кеш засоряется

Postgres кеширует страницы данных в специальных буферах, для эффективного обмена нужными данными.
Когда ты выбираешь *, кеш наполняется ненужными колонками.
А потом, когда реально нужный запрос приходит — места уже нет 🤷‍♂️

💡 Вывод:

SELECT * — это как “всё включено” в отеле, где ты ешь один салат, но платишь за омаров, вино и шоу с фаерболами.
Пиши явно, что тебе нужно. PostgreSQL скажет “спасибо” и даст красивый план с INDEX ONLY SCAN.

Наверное многие слышали что * это плохо, но мало кто понимает почему. Это конечно не простая тема, если будут вопросы по пунктам пишите, буду пояснять.