SQL: Реляционные базы данных

🐘 От академического проекта до лидера open-source: история PostgreSQLПродолжим тему постов про историю SQL и СУБД, ранее мы уже разбирали:➖ Как создатель MySQL потерял миллиарды➖ Историю SQL: от лаборатории IBM до ядра современного ИТТеперь настало время одной из самых популярных промышленных СУБД — PostgreSQL ❗️ Начало, проект "Ingres"Всё началось в 1986 году в Калифорнийском университете в Беркли. Группа исследователей под руководством профессора Майкла Стоунабрейкера уже создала реляционную СУБД Ingres — одну из первых в мире. Но им захотелось большего. Они решили пойти дальше реляционной модели и создать объектно-реляционную СУБД, которая поддерживала бы сложные типы данных, наследование и пользовательские функции. Так родился проект Post-Ingres — "после Ingres".❗️ Рождение open-sourceВ 1994 году два аспиранта Андреас Энглесберг и Джонсон Ло портировали Postgres на язык C и добавили поддержку SQL. Это стало поворотным моментом. В том же году код был открыт под лицензией BSD и началась эра сообщества. В 1996 году название изменили на PostgreSQL, чтобы подчеркнуть совместимость со стандартом. PostgreSQL — одна из самых старых open-source СУБД, которая активно развивается без корпоративного владельца. Никакой Oracle, Microsoft или Google за спиной — только сообщество энтузиастов и профессионалов. ❗️ Эволюция версий: от 6.0 до 16+➖ 1996: Выходит PostgreSQL 6.0 — первая официальная версия с SQL.➖ 1997: Появляется поддержка транзакций и многоверсионного контроля параллелизма (MVCC) — технологии, которая сегодня лежит в основе производительности PostgreSQL.➖ 2005: Версия 8.0 — первая нативная сборка для Windows.➖ 2010: Поддержка JSON (ещё до бума NoSQL!).➖ 2012: JSONB — бинарный, индексируемый JSON. Это стало прорывом: PostgreSQL начал конкурировать с документными базами.➖ 2018: Версия 11 — параллельное создание индексов, улучшенная масштабируемость.➖ 2023: PostgreSQL 16 — улучшения в логической репликации, безопасность, производительность аналитических запросов.➖ 202

Если вы задумывались над тем, чем же все-таки занимаются аналитики, рекомендую подписаться на канал Data Brew!Канал ведет тот самый аналитик, который смог построить карьеру после курсов и сейчас продолжает расти профессионально.Автор🤗 помогает в поиске работы😊пишет о полезных для аналитиков хардах🎁делится реальными историями с собеседований🤬 рассказывает о боли аналитиков😇 скидывает аналитические мемыПодписывайся на @data_brew

❗️ HAVING в SQLМногие думают, что оператор HAVING — это просто аналог WHERE, но после GROUP BY. Это упрощение, которое может привести к путанице. Давайте разберём настоящую теорию — шаг за шагом.Здесь нужно понимать, что SQL-запрос выполняется СУБД не в том порядке, в котором он написан человеком. Это критически важно для понимания HAVING.❗️ Логический порядок с точки зрения исполнения СУБД (упрощённо):1. FROM — загрузка данных из таблиц(ы)2. WHERE — фильтрация отдельных строк3. GROUP BY — разбиение оставшихся строк на группы4. Вычисление агрегатных функций (COUNT, SUM, AVG и т.д.) для каждой группы5. HAVING — фильтрация групп на основе результатов агрегации6. SELECT — формирование выходных колонок (включая алиасы)7. ORDER BY, LIMIT, и т.д.⛔️ Именно потому, что агрегаты появляются только на шаге 4, их нельзя использовать в WHERE — на момент выполнения WHERE (шаг 2) групп ещё не существует!❗️ HAVING — это условие в SQL, которое фильтрует группы строк после того, как они были объединены с помощью GROUP BY.❗️ Что такое «группа» в реляционной алгебре?SQL основан на реляционной алгебре. Оператор GROUP BY трансформирует отношение (таблицу) в множество групп, где каждая группа — это подмножество строк с одинаковым значением ключа группировки.Пример:GROUP BY departmentCоздаёт столько групп, сколько уникальных значений в колонке department. Каждая такая группа — новая логическая единица, и к ней можно применять агрегатные функции, которые сводят множество строк к одному значению (например, средняя зарплата в отделе).❗️ Почему WHERE не может работать с агрегатами?Потому что WHERE работает на уровне кортежей (строк), а не групп. Он отвечает на вопрос: «Оставить ли эту конкретную строку в результирующем наборе до группировки?». Агрегатные функции, напротив, не определены для одной строки — они требуют множества. Например, AVG(salary) для одной строки — это просто salary, но SQL не позволяет так делать в WHERE, чтобы избежать семантической неоднозначности.❗️ Когда использовать H

Узнайте, почему ваши SQL-запросы тормозят 🤖Медленные SQL-запросы могут стоить бизнесу миллионов: отчёты считаются часами, решения принимаются с задержкой, а ошибки в данных подрывают доверие к аналитике.На вебинаре Владимир Лунев, бизнес- и системный аналитик с 5-летним опытом работы в ритейле и IT, разберёт 7 реальных кейсов оптимизации SQL-запросов, которые помогали бизнесу принимать быстрые и точные решения.В ходе вебинара разберём:🟠 Как понять, что запрос тормозит, и чем это грозит бизнесу;🟠 Как читать план выполнения (EXPLAIN, EXPLAIN ANALYZE) и находить ошибки;🟠 Типовые причины медленных запросов и как их исправлять;🟠 7 реальных кейсов из практики: «было → стало» с разбором кода.❗️ Встречаемся 24 сентября в 19:00 МСК.🧡 Обязательно ждём вас в лайве — вы сможете напрямую задать свои вопросы Владимиру Луневу и получить ценный опыт оптимизации SQL-запросов!➡️ Зарегистрироваться на вебинар📊 Simulative

📥 Гайд по LIMIT и OFFSETКогда вы работаете с большими таблицами, часто не нужны все строки сразу. Например, вы хотите:➖ показать топ-10 самых дорогих товаров,➖ вывести последние 20 заказов,➖ сделать постраничную навигацию в приложении.➖ вам просто лень писать фильтры, ведь для анализа/оценки хватит n-строк таблицы. НО учтите что будет полное сканирование таблицы! Для этого в SQL есть два оператора (точнее clauses): LIMIT и OFFSET.📥 LIMIT — сколько строк выбрать.LIMIT ограничивает количество строк, которое вернёт запрос.Пример:SELECT * FROM productsORDER BY price DESCLIMIT 5; -- берём только 5 самых дорогих товаровЧто происходит:➖ ORDER BY price DESC — сортируем товары по убыванию цены.➖ LIMIT 5 — берём только первые 5 строк после сортировки.📥 Советы:➖ Без ORDER BY LIMIT вернёт произвольные строки — на больших таблицах результат может быть сомнительным.➖ LIMIT экономит ресурсы: не нужно считывать все данные, когда вам нужны только несколько строк.📥 OFFSET — с какой строки начать.OFFSET пропускает указанное количество строк перед выборкой.Пример:SELECT * FROM productsORDER BY price DESCLIMIT 5 OFFSET 5; -- берём строки с 6 по 10Что происходит:➖ Сортируем товары по цене (ORDER BY price DESC).➖ Пропускаем первые 5 строк (OFFSET 5).➖ Берём следующие 5 строк (LIMIT 5).🪙 Практическое применение: пагинацияLIMIT + OFFSET идеально подходят для страниц сайта или приложения (бэк UI), но можно юзать и при подготовке отчетности, если ложиться в условия ее формирования.-- Страница 1SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 0;-- Страница 2SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 20;-- Страница 3SELECT * FROM orders ORDER BY order_date DESC LIMIT 20 OFFSET 40;Каждый раз вы берёте новую порцию данных без лишней нагрузки на базу.🪙 Стоит упомянуть: Случайные строки с LIMIT. Чтобы взять случайные строки из таблицы:SELECT * FROM usersORDER BY RANDOM() -- в разных СУБД отличается LIMIT 5;LIMIT в подзапросах. Можно использовать LIMIT для выбор

Всем привет)) Совместно @simulative_official организуем буткемп по SQL, регистрация доступна уже сейчас, буду рад вашему участию 👩‍💻

Привет, аналитики! Меня зовут Владимир Лунев. Более 5 лет я работаю в IT как бизнес- и системный аналитик.Я строил процессы и архитектуру реляционных баз данных для аналитиков, чтобы они могли быстро получить качественные данные, а не заниматься ручной обработкой исходной информации. Большую часть карьеры провёл в ритейле, где ежедневно принимаются решения на основе больших потоков данных: продаж, запасов, логистики, прогнозов спроса.Я часто сталкивался с задачами, где точность и скорость обработки данных имели критическое значение: приходилось быстро выявлять скрытые ошибки, обеспечивать корректность бизнес-отчётов и автоматизировать расчёты ключевых показателей.Несколько кейсов из моей работы:👑 Оптимизировал отчёт и сократил время его выполнения с 3 часов, до 30 минут, не переписывая бизнес-логику, а разобрав EXPLAIN и исправив ошибки SQL-запросов.👑 Построил систему контроля качества данных на основании проверочных скриптов, которая автоматически ловила дубли, NULL-ловушки и логические противоречия до попадания информации в отчёты.👑 Разработал автоматизированный процесс агрегации и расчёта KPI для сети магазинов, позволивший ежедневно получать корректные метрики без ошибок.Я буду ведущим SQL-буткемпа — практикума, где вы получите реальные навыки, которые работают в боевых проектах бизнеса. В рамках буткемпа мы разберём:➖Оптимизацию запросов в SQL — разбор EXPLAIN, выявление «тормозящих» мест, исправление лишних подзапросов и «фантомных» строк для ускорения критичных бизнес-отчётов и выгрузок.➖Контроль качества данных — научимся писать кастомные скрипты проверок данных для точных и надёжных данных.➖Прогнозы и тренды — построение когорт, скользящих метрик, lag/lead-анализ и простые линейные прогнозы для точного планирования.➖Сценарный анализ «что если» — моделирование альтернатив через параметризацию, temp-таблицы и CTE, автоматизация расчётов для оценки влияния изменений на ключевые показатели.➖ Агрегацию данных и полезные бизнес-метрики — расчёт growth, hitrate

👩‍💻 Он создал MySQL — и потерял миллиарды. История, о которой редко рассказывают.Привет, сегодня лайтовая история про создателя 2-х весьма популярных СУБД, решил писать больше такого контента, а не только делать разборы запросов)Итак, слышал про MySQL?Это не просто СУБД — это фундамент, на котором вырос весь интернет 2000-х. А придумал её финский программист — почти в одиночку. Его зовут Микаэль "Монти" Видениус.❗️ Кто такой Монти➖ Родился в 1962 году в Хельсинки. В 4 года попал в аварию и всю жизнь хромает. В школе спорт не шёл, зато компьютеры стали главным увлечением.➖ Первый код написал в 1970-х, а в 19 лет уже делал программы для бизнеса.➖ Учился в Хельсинкском техническом университете, не окончив его, в 1981 году начал работать в компании Тапио Лааксо. ➖ В 1985 году совместно с Аланом Ларссом основал компанию TCX DataKonsult. В 1994 году вместе с Давидом Аксмарком приступил к созданию первой версии MySQL. В следующем году совместно с Ларрсом и Аксмарком основал компанию MySQL AB, нацеленную на коммерциализацию продукта.❗️ Как это было➖ Монти получил от клиента просьбу сделать простую базу «для веба», в результате размышлений над задачей родилась идея новой СУБД. Он берёт концепт движка mSQL, переписывает его с нуля и создаёт MySQL — базу, которая изменит интернет. Монти называет ее в честь дочери: My + SQL.❗️ MySQL он выкладывает в сеть:➖ бесплатно,➖ с открытым кодом,➖ с установкой «за 5 минут».Разработчики в восторге: «Наконец-то альтернатива Oracle, за которую не нужно платить тысячи долларов!»MySQL становится стандартом веба.❗️ Как потерять миллиарды➖ 2008 год. MySQL используют Google, NASA, Mail Group, «Яндекс».➖ Монти был техническим директором MySQL AB вплоть до её продажи компании Sun Microsystems в январе 2008 года. ➖ Компания Sun покупает MySQL AB за $1 млрд. А Монти зарабатывает на сделке около 16,6 миллионов евро. Казалось бы — успех! Но:➖ Монти получил лишь часть от сделки — и упустил шанс стать одним из самых богатых людей в IT. А ведь MySQL ста

⌛ Основы по работе с датами в SQL. Часть 2/3Привет, продолжаем разбор основ начатый в предыдущем посте. Там мы разобрали:➖ Основные типы данных для хранения дат.➖ Функции получения текущего времени.➖ Извлечение отдельных компонентов даты и времени.Для инфо синтаксис в коде постов пишу для PostgreSQL (как популярной промышленной СУБД, для других логика похожа, но синтаксис может отличаться, гуглите) ⌛ Арифметика с датами: работа с интерваламиSQL позволяет выполнять математические операции с датами — добавлять/вычитать дни, месяцы, годы и другие временные интервалы.-- Предположим, у нас есть дата: '2024-03-15 14:30:25'SELECT created_at, -- Исходная дата: 2024-03-15 14:30:25 -- Добавляем 7 дней (также можно и с месяцами - '2 months') -- Результат: 2024-03-22 14:30:25 created_at + INTERVAL '7 days' AS one_week_later, -- Вычитаем 3 дня -- Результат: 2024-03-12 14:30:25 created_at - INTERVAL '3 days' AS three_days_ago, -- Добавляем 1 год -- Результат: 2025-03-15 14:30:25 created_at + INTERVAL '1 year' AS next_year, -- Добавляем 3 часа -- Результат: 2024-03-15 17:30:25 created_at + INTERVAL '3 hours' AS three_hours_later, -- Добавляем 30 минут -- Результат: 2024-03-15 15:00:25 created_at + INTERVAL '30 minutes' AS thirty_minutes_later, -- Комбинируем интервалы -- Результат: 2025-04-22 17:45:25 (через 1 год, 1 месяц, 7 дней, 3 часа, 15 минут) created_at + INTERVAL '1 year' + INTERVAL '1 month' + INTERVAL '7 days' + INTERVAL '3 hours' + INTERVAL '15 minutes' AS complex_intervalFROM ordersWHERE id = 123;⌛ Вычисление разницы между датамиЧасто нужно узнать, сколько времени прошло между двумя событиями — для этого есть специальные функции.-- Считаем разницу между двумя конкретными датами в днях-- Результат: 7 (разница в днях между 15 марта и 22 марта)SELECT '2024-03-22'::date - '2024-03-15'::date AS days_difference;-- Считаем разницу между датой заказа и текущей датойSELECT created_at, -

⌛ Основы по работе с датами в SQL. Часть 1/3Работа с датами и временем — это неотъемлемая часть большинства SQL-запросов. Независимо от того, анализируете ли вы продажи по месяцам, фильтруете данные за определённый период или рассчитываете сроки выполнения задач — понимание работы с датами просто необходимо. Перед тем как начинать работать с датами, важно понять, как именно они хранятся в различных СУБД (определите вашу и погуглите какой синтаксис она приветствует), это поможет избежать множества ошибок и неожиданностей.⌛ Основные типы данных для хранения дат:➖ DATE — хранит только дату без времени➖Формат: YYYY-MM-DD (например: 2024-03-15)➖Диапазон: от 1000-01-01 до 9999-12-31➖Использование: когда важна только дата (день рождения, дата регистрации)➖TIME — хранит только время суток➖Формат: HH:MM:SS (например: 14:30:25)➖Может включать: микросекунды HH:MM:SS.ffffff➖Использование: время начала/окончания рабочего дня, длительность процессов➖ DATETIME — хранит дату и время вместе➖Формат: YYYY-MM-DD HH:MM:SS (например: 2024-03-15 14:30:25)➖Диапазон: от 1000-01-01 00:00:00 до 9999-12-31 23:59:59➖Использование: временные метки событий, логи➖ TIMESTAMP — похож на DATETIME, но с важными отличиями:➖Диапазон: от 1970-01-01 00:00:01 UTC до 2038-01-19 03:14:07 UTC➖Автоматическое обновление: может обновляться при изменении строки➖Часовой пояс: часто зависит от настроек сервера➖Использование: когда важна временная зона и автоматическое обновлениеДальше распишу функционал внутри кода, для наглядности.⌛ Функции получения текущего времени.Эти функции используются постоянно — для фильтрации свежих данных, создания временных меток, сравнения с прошлыми значениями.-- Получаем только текущую дату (без времени)-- Результат будет примерно таким: 2024-03-15SELECT CURRENT_DATE;-- Альтернатива:SELECT CURDATE(); -- То же самое в MySQL-- Получаем текущую дату и время-- Результат будет примерно таким: 2024-03-15 16:45:30SELECT NOW();-- Альтернативы:SELECT CURRENT_TIMESTAMP; -- То же самое, что и

Никогда не забывайте про WHERE 😂

🪙Junior-ready: выучить SQL и пройти собесы. Часть 1/2Набросал своеобразную карту навыков и знаний необходимых для базового, но уверенного понимания работы с реляционными БД. У поста будет еще вторая часть, больше про сами собесы и задачки на них. А пока основы:📤 Освойте синтаксис базовых SQL-запросов.Начинать нужно с основ. Вы должны понимать, как извлекать данные из таблиц и как управлять результатом запроса. Разберитесь с базовыми конструкциями:➖ SELECT — выбор данных (всех или конкретных столбцов)➖ FROM — указание таблицы, из которой берутся данные➖ WHERE — фильтрация строк по заданным условиям➖ AND / OR — логические связки условий➖ ORDER BY — сортировка результатов➖ LIMIT — ограничение количества строк➖ LIKE, IN, BETWEEN — работа с шаблонами, списками и диапазонамиУже на этом этапе вы сможете решать до 40% практических задач, особенно из области аналитики или SQL-тестов на позицию junior.📤 Понимание соединений таблиц (JOIN).В большинстве реальных задач данные разбросаны по нескольким таблицам. Чтобы собрать полную картину, нужно уметь соединять таблицы между собой. Разберитесь с основными типами соединений:➖ INNER JOIN — возвращает только те строки, где есть совпадения в обеих таблицах➖ LEFT JOIN — сохраняет все строки из левой таблицы, даже если нет совпадений в правой➖ RIGHT JOIN и FULL JOIN — менее распространены, но могут пригодиться в BI и отчётностиПонимание JOIN — обязательный навык. Ошибки в соединениях часто приводят к неверным результатам и срезают кандидатов на собеседованиях.📤 Агрегатные функции и группировка.Вам нужно научиться считать и группировать данные, это важно для аналитики через SQL. Изучите:➖ Агрегатные функции: SUM, AVG, MIN, MAX, COUNT➖ GROUP BY — группировка строк по значениям одного или нескольких столбцов➖ HAVING — фильтрация уже агрегированных результатов (в отличие от WHERE)На этой базе строится вся аналитика: подсчёты по клиентам, категориям, регионам и т.д.📤 Работа с датами и временемМногие задачи связаны с анализом по дням,

🧊 Айсберг SQLОднажды, наткнулся на забавный мем, который с каждым уровнем становится все сложнее и страшнее, посмеялся и забыл. А недавно нашёл статью на Хабр и оказалось, что у мема есть реальное практическое применение, ведь он, по сути, этап за этапом разбирает взаимодействие через SQL с СУБД PostgreSQL, а автор мема SQL-разработчик Джордан Льюис. Так что можно использовать мем, чтобы выстроить свой путь изучения SQL, как методичку)) На этой неделе, кстати, опубликую пост, как быстро погрузиться в SQL, если вы новичок, и за пару недель (или меньше) достичь гордого уровня junior, минимально необходимого для прохождения собеседований.

📥 Что такое CTE (WITH) в SQL?CTE (Common Table Expression) — это временный результирующий набор данных, определённый в WITH-блоке и используемый внутри основного SQL-запроса. Он существует только в рамках одного запроса и не сохраняется в базе.По сути, это "виртуальная подтаблица", которую можно использовать как обычную таблицу, но без создания объекта в БД.Зачем нужен CTE?➖ Упрощает структуру запроса. Вместо вложенных подзапросов (особенно повторяющихся), можно дать промежуточным результатам имена и вынести их в WITH.➖ Повышает читаемость. Каждый WITH-блок как отдельный логический шаг, как в пайплайне обработки данных.➖ Упрощает отладку. Можно легко запускать отдельные WITH-блоки как обычные SELECT-запросы и проверять результаты.➖ Поддерживает рекурсию. С помощью WITH RECURSIVE можно обходить иерархии, строить деревья и графы.🪙Общий синтаксис:WITH имя_cte (опциональные_поля) AS ( SQL-запрос)SELECT ...FROM имя_cte...WITH объявляет формирование CTE. Можно создавать несколько CTE за один раз, разделяя их запятыми:WITH cte1 AS (...), cte2 AS (...)SELECT ...FROM cte1JOIN cte2 ...🪣 Давайте разберем на примере. Задача:Найти всех пользователей, которые заходили в систему за последние 30 дней, и посчитать, сколько заказов сделал каждый из них.💳 Модель данных:➖ Таблица пользователи — users (id, name, last_login)Атрибуты: ➖users.id — уникальный идентификатор пользователя, первичный ключ.➖users.name — имя пользователя, текстовое поле. ➖users.last_login — дата (или дата и время) последнего входа в систему, используется для фильтрации активных пользователей.🪙Полный состав таблицы users по данным: id name last_login101 Иван 2025-07-20 105 Ольга 2025-07-15 109 Петр 2025-06-10➖ Таблица заказы — orders (id, user_id, created_at). Атрибуты: ➖orders.id — уникальный идентификатор заказа, первичный ключ. ➖orders.user_id — внешний ключ на users .id, связывает заказ с пользователем. ➖orders.created_at — дата (или дата и время) создания заказа.🪙 Полный состав таблиц

👩‍💻 Генерация ключей в SQL: что выбрать — UUID, INT или BIGINT?При проектировании таблиц в реляционных базах данных важно выбрать тип данных для первичного ключа. От него зависят скорость запросов, обеспечение уникальности, масштабируемость и даже архитектура системы. Даже если вы не проектируете БД, понимание ключей поможет в работе с данными. 🖥 Если необходимо, можете прочитать пост про первичный ключ и базовый автоинкримент тутВ этом посте рассмотрим три популярных способа генерации первичных ключей: INT, BIGINT и UUID. 🛠 INT — автоинкрементный числовой ключ. Используется по умолчанию в большинстве проектов. Он требует минимум места, обеспечивает быструю сортировку и фильтрацию по индексу, хорошо читается в логах, легко реализуется средствами СУБД. Но у INT есть потолок (2.1 млрд значений) и ограниченная масштабируемость: при распределении на несколько серверов ID могут пересекаться. А ещё ID легко угадываются, что делает структуру базы предсказуемой.✅ Подходит для централизованных систем с небольшим или средним объёмом данных, занимает минимум места в памяти и индексах, понятен при отладке и в логах.✅ Быстрота отличная производительность при сортировке и фильтрации по индексу.✅ Легко реализуется с AUTO_INCREMENT или SERIAL.❌ ID легко предсказуемы, что может косвенно раскрывать объёмы или порядок операций, также при ошибке планирования в крупных системах может потребоваться переход на BIGINT.❌ Сложность масштабирования, трудно синхронизировать генерацию ID между несколькими узлами.🛠 BIGINT — INT с запасом на вырост. То же самое, только 64 бита. Решает проблему переполнения — хватит на миллиарды строк. Сохраняет читаемость, скорость и простоту реализации. Поддерживается всеми современными СУБД. Но индекс и таблицы с такими ключами весят больше. А генерация ID всё ещё централизованная, что не даёт гибкости.✅ Уместен в крупных монолитных системах с интенсивной вставкой данных (например, финансы, e-commerce).✅ Сохраняет преимущества INT — скорость, простота, чит