4 преимущества использования колоночных СУБД. Для чего они применяются и в чем их слабость.

Колоночная СУБД — это тип системы управления базами данных, в котором данные хранятся и организованы по колонкам, а не по строкам, как в традиционных реляционных СУБД. Колоночные СУБД имеют ряд преимуществ и применяются для решения определенных задач:

1. Эффективность при аналитических запросах: Колоночные СУБД предназначены для обработки аналитических запросов, которые часто требуют агрегации и анализа больших объемов данных. Такая организация данных по колонкам позволяет быстро извлекать и анализировать только необходимые колонки, минимизируя объем данных для чтения и ускоряя выполнение запросов.

2. Компрессия данных: Колоночные СУБД часто применяют сжатие данных, что позволяет уменьшить объем занимаемого пространства на диске. Это особенно важно при работе с большими объемами данных, где эффективное использование дискового пространства может существенно сэкономить ресурсы хранения.

3. Параллельная обработка: Колоночная организация данных позволяет эффективно распараллелить выполнение запросов и операций агрегации. Каждая колонка может обрабатываться независимо, что увеличивает производительность и позволяет быстро обрабатывать большие объемы данных.

4. Оптимизация для чтения: Колоночные СУБД оптимизированы для операций чтения данных, так как они активно используются в аналитических работах и поисковых запросах, где скорость извлечения данных является критическим фактором.

Колоночные СУБД наиболее часто применяются для аналитических и отчетных задач, где нужно обрабатывать большие объемы данных и проводить сложные агрегации и анализы. Прирост скорости выполнения запросов может достигать 10-ти кратных величин. Только не подумайте теперь, а зачем нам тогда реляционная СУБД=).

У колоночных СУБД есть и недостатки. Они медленно работаю работают на запись данных, не подходят для транзакционных систем и т д.

Как в PostgreSQL посчитать разницу в часах между двумя полями с типами timestamp?

Допустим у нас есть дата – время взятия продукта в аренду и дата – время возврата продукта. Наша задача посчитать разницу в часах, то есть столько продукт находился в аренде.

В примере на скриншоте два варианта:

В первом при помощи функции AGE мы находим разницу между датами в типе INTERVAL, далее при помощи конструкции EPOCH и функции EXTRACT вычисляем данную разницу в секундах, делим на 3600 и получаем искомые часы.

Во втором варианте еще проще, вычитаем из одной даты другую, а при помощи конструкции EPOCH и функции EXTRACT вычисляем данную разницу также в секундах.

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

Партиционирование в SQL.

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

Партиционирование может быть полезно в следующих случаях:

1. Управление объемом данных: Если таблица содержит большое количество записей, партиционирование может помочь управлять этим объемом данных. Запросы могут выполняться более эффективно на отдельных партициях, и операции обслуживания данных могут быть более быстрыми и менее нагруженными.

2. Улучшение производительности: Партиционирование может ускорить выполнение запросов, разделяя данные между различными физическими дисками или массивами хранения. Это позволяет параллельно обрабатывать запросы на разных партициях, улучшая производительность системы в целом.

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

SQL-синтаксис для создания партиций и управления ими может различаться в зависимости от конкретной реализации базы данных. Различные базы данных имеют свои собственные подходы к этому процессу.

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

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 году,
нужно сочетать инструменты, логику и умение объяснять данные людям.