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

описание

Канал айтишника о реляционных базах данных, SQL и модели данных. У нас тут много, очень много практических разборов)) Меня зовут Владимир Лунев (@lejnlune). Интересуюсь архитектурой систем и моделей данных.

← к каналу @relational_databases

989

подписчиков

Охват к подписчикам

122,4%

ERR

Реакции к просмотрам

3,04%

837 на 25 постов

Пересылки к просмотрам

1,16%

320

Постов в день

0,0

всего 25

Где отзываются чаще

доля реакций к просмотрам

3 маяВсем привет)) Я вернулся, так что с этой недели будут новые посты, будем воскрешать канал. Пропадал из за загруженности на работе и своих проектах.6,67%
28 июн.👩‍💻 Типы данных в PostgreSQL: как они устроены и почему их выбор имеет значение Одна из самых распространенных ошибок при проектировании базы данных это выбирать типы данных по принципу "лишь бы поместилось". На самом деле тип данных определяет не только допустимые значения, но и способ их хранения, объем занимаемой памяти, производительность запросов и размер индексов. PostgreSQL предоставляет широкий набор встроенных типов данных, каждый из которых предназначен для решения определенных задач. В этом посте коротко, постарался описать, основные типы которые встречаются в постгре. Тут кста пост про то как создали постгре 🖥 ❗️ Целочисленные типы Для хранения целых чисел PostgreSQL предоставляет три основных типа: SMALLINT INTEGER BIGINT ➖ SMALLINT занимает 2 байта и хранит значения в диапазоне от -32 768 до 32 767. ➖ INTEGER (или сокращенно INT) занимает 4 байта и является наиболее часто используемым типом. Его диапазон составляет от -2 147 483 648 до 2 147 483 647. ➖ BIGINT занимает 8 байт и используется, когда диапазона INTEGER недостаточно, например для очень больших идентификаторов или счетчиков. Типы SERIAL, BIGSERIAL и SMALLSERIAL не являются отдельными типами данных. Это специальная запись, которая автоматически создает последовательность (SEQUENCE) и задает значение по умолчанию для соответствующего целочисленного столбца. При выборе типа рекомендуется использовать минимально достаточный размер. Это позволяет уменьшить объем хранения данных и размер индексов, хотя в современных системах влияние на производительность обычно менее заметно, чем влияние правильно построенных индексов и структуры запросов. ❗️ Числа с фиксированной точностью Для хранения значений, где важна абсолютная точность, используются типы NUMERIC и DECIMAL. price NUMERIC(10,2) Первый параметр определяет максимальное количество цифр, второй, количество цифр после десятичной точки. Например: 99999999.99 Главное преимущество NUMERIC это возможность хранить десятичные числа с заданной точностью без ошибок представления, характерных для чисел с плавающей точкой. В отличие от типов с плавающей точкой, каждое значение хранится с заданной точностью. Именно поэтому все финансовые расчеты, бухгалтерские операции и денежные суммы рекомендуется хранить в NUMERIC. Следует учитывать, что операции над такими числами требуют больше вычислений и обычно выполняются медленнее, чем над целыми числами. ❗️ Числа с плавающей точкой В PostgreSQL используются типы: REAL DOUBLE PRECISION Также поддерживается запись FLOAT(p) где значение p определяет необходимую точность. В зависимости от нее постгре автоматически использует либо REAL, либо DOUBLE PRECISION. Если p ≤ 24, используется REAL, иначе (до 53) будет DOUBLE PRECISION. Эти типы реализованы в соответствии со стандартом IEEE 754. Число хранится в виде знака, экспоненты и мантиссы, благодаря чему поддерживается очень широкий диапазон значений. Однако далеко не каждую десятичную дробь можно представить точно в двоичной системе. Например: SELECT 0.1 + 0.2; может вернуть 0.30000000000000004 Это нормальное поведение чисел с плавающей точкой, а не ошибка СУБД. Поэтому REAL и DOUBLE PRECISION подходят для инженерных расчетов, статистики и научных вычислений, но не для хранения денежных сумм. ❗️ Символьные типы Наиболее часто используются три типа: CHAR(n) VARCHAR(n) TEXT ➖ CHAR(n) хранит строки фиксированной длины. Если фактическая длина меньше указанной, PostgreSQL дополняет значение пробелами до нужного размера. Такой тип имеет смысл использовать только тогда, когда длина значения всегда одинакова, например для кодов стран или сокращений. ➖ VARCHAR(n) хранит строки переменной длины и дополнительно проверяет, что значение не превышает указанное ограничение. ➖ TEXT также хранит строки переменной длины, но без ограничения размера. Интересная особенность PostgreSQL заключается в том, что TEXT и VARCHAR используют практически одинаковый механизм хранения. На практике различий в производительности между ними практически нет. Единственное отличие состоит в том, что VARCHAR(n) выполняет дополнительную проверку максимальной длины строки при записи данных. Именно поэтому многие разработчики PostgreSQL предпочитают использовать TEXT, если ограничение длины не является бизнес-требованием. ❗️ Дата и время Для хранения временных данных PostgreSQL предоставляет несколько специализированных типов: DATE TIME TIMESTAMP TIMESTAMPTZ ➖ DATE хранит только календарную дату. ➖ TIME содержит только время суток. ➖ TIMESTAMP хранит дату и время без информации о часовом поясе. ➖ TIMESTAMPTZ (Timestamp with Time Zone) хранит момент времени с учетом часового пояса. Внутри PostgreSQL такие значения преобразуются в UTC, а при выводе отображаются в часовом поясе текущей сессии. Оба типа TIMESTAMP занимают 8 байт и представлены как количество микросекунд относительно внутренней эпохи PostgreSQL. Благодаря этому операции сравнения, сортировки и вычисления интервалов выполняются очень эффективно. ❗️ Логический тип Для хранения булевых значений используется тип BOOLEAN Он занимает 1 байт и поддерживает значения: TRUE FALSE NULL PostgreSQL также понимает различные формы записи при вводе значения, например 1, 0, yes, no, on, off, автоматически преобразуя их в логические значения. ❗️ Бинарные данные Для хранения произвольной последовательности байтов используется тип: BYTEA Он подходит для хранения изображений, документов, архивов и других бинарных объектов. Для очень больших файлов постгре также предоставляет механизм Large Objects, который позволяет хранить данные отдельно от основной таблицы и работать с ними потоково, но на самом деле он используется значительно реже, чем BYTEA, и обычно нужен лишь для действительно крупных объектов. ❗️ Специализированные типы PostgreSQL Одно из преимуществ постгри это наличие типов данных, отсутствующих во многих других СУБД. ➖ UUID - используется для хранения глобально уникальных идентификаторов (пост про юиды тут 😎) id UUID UUID занимает 16 байт и позволяет генерировать уникальные идентификаторы без обращения к последовательностям. ➖ JSON и JSONB JSON JSONB JSON хранит исходный текст документа. JSONB преобразует данные во внутренний бинарный формат, позволяющий создавать индексы и выполнять быстрый поиск по содержимому. В большинстве случаев именно JSONB является предпочтительным выбором. ➖ ARRAY - PostgreSQL поддерживает массивы как полноценный тип данных. tags TEXT[] scores INTEGER[] Это позволяет хранить несколько значений в одном поле без создания отдельных таблиц для хранения небольших коллекций значений, хотя применять массивы следует только тогда, когда это действительно оправдано моделью данных. ➖ ENUM - Позволяет определить собственный тип с фиксированным набором значений. Например: CREATE TYPE order_status AS ENUM ( 'new', 'paid', 'shipped', 'completed' ); Такой подход обеспечивает контроль допустимых значений на уровне базы данных. Тип данных в PostgreSQL определяет значительно больше, чем допустимый формат значения. Он влияет на внутреннее представление данных, объем хранения, размер индексов, скорость выполнения запросов и возможности оптимизатора. Чем точнее выбран тип данных на этапе проектирования схемы, тем эффективнее будет работать база данных при росте объема информации. Именно поэтому грамотное проектирование БД начинается не с написания запросов, а с выбора подходящих типов данных. #SQL #Типы_данных #PostgreSQL 📱 Подписаться на канал 💻 Курс автора по SQL DDL 👩‍💻Nodus4,71%
23 авг. 2025 г.Никогда не забывайте про WHERE 😂4,41%
28 июн.Краткий справочник по типам данных к посту4,23%
8 сент. 2025 г.👩‍💻 Он создал 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 стал фундаментом интернета — его ценность сегодня могла бы исчисляться десятками миллиардов. ➖ А вскоре Sun поглощает… Oracle — главный конкурент MySQL. И вместе с потенциальными миллиардами уходит контроль над судьбой проекта. ❗️ Восстание ➖ 12 декабря 2009 года Монти обратился к сообществу с просьбой написать в Еврокомиссию письма за предотвращение поглощения Sun Microsystems корпорацией Oracle в связи с возможной монополизацией рынка СУБД, так как в результате сделки Oracle получала права на MySQL и активы MySQL AB, но не смотря на это, поглощение было одобрено. ➖ Монти решает: «Раз так — будет новая база». Берёт открытую версию MySQL и делает форк. Называет его в честь младшей дочери — MariaDB. ➖По задумке MariaDB — это MySQL, только свободнее. Без Oracle. С открытым будущим и со своими улучшениями — от скорости до масштабируемости. Сегодня её используют Wikipedia, Google Cloud, «СберТех». ➖ Однако, со временем архитектуры разошлись. Где-то MariaDB быстрее, где-то — MySQL. MariaDB добавила много нового (например, движок ColumnStore, улучшенную репликацию), но и MySQL не стоит на месте и пытается активно конкурировать с другими СУБД сегмента. ❗️ А что Oracle? Oracle вынужден развивать MySQL: слишком много зависимых проектов. А MariaDB растёт и отбирает долю рынка. ❗️ Что сейчас с Монти? Живёт в Финляндии, пишет код, ему за 60. Не миллиардер. Просто инженер, который сделал интернет и работу с БД удобнее. ❗️ Подведем мораль? ➖ Можно создать продукт, который меняет мир — и не заработать на нём. ➖Можно лишиться своего детища — и вырастить новое, ещё сильнее. ➖А можно просто продолжать кодить. И быть счастливым. А ты бы выбрал миллиарды — или свободу кода? #SQL #Факты 📱 Подписаться на канал 💻 Курс автора по SQL DDL 🌎 Мой ИТ-стартап3,81%
28 авг. 2025 г.⌛ Основы по работе с датами в 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-15 SELECT CURRENT_DATE; -- Альтернатива: SELECT CURDATE(); -- То же самое в MySQL -- Получаем текущую дату и время -- Результат будет примерно таким: 2024-03-15 16:45:30 SELECT NOW(); -- Альтернативы: SELECT CURRENT_TIMESTAMP; -- То же самое, что и NOW() SELECT LOCALTIME(); -- В некоторых СУБД SELECT LOCALTIMESTAMP(); -- В некоторых СУБД -- Получаем только текущее время (без даты) -- Результат будет примерно таким: 16:45:30 SELECT CURRENT_TIME; -- Альтернатива: SELECT CURTIME(); -- То же самое в MySQL ⌛ Извлечение отдельных компонентов даты и времени. Часто нужно получить отдельные части даты — год, месяц, день и т.д. Для этого используются функции извлечения. -- Представим, что у нас есть таблица orders с полем created_at -- Значение created_at: '2024-03-15 14:30:25' SELECT created_at, -- Исходное значение: 2024-03-15 14:30:25 -- Извлекаем год из даты -- Результат: 2024 EXTRACT(YEAR FROM created_at) AS order_year, -- Извлекаем месяц из даты -- Результат: 3 (март) EXTRACT(MONTH FROM created_at) AS order_month, -- Извлекаем день месяца -- Результат: 15 EXTRACT(DAY FROM created_at) AS order_day, -- Извлекаем день недели (0 = воскресенье, 1 = понедельник, ...) -- Результат: 6 (суббота) EXTRACT(DOW FROM created_at) AS day_of_week, -- Извлекаем день года (1-365/366) -- Результат: 75 (15 марта — 75-й день года) EXTRACT(DOY FROM created_at) AS day_of_year, -- Извлекаем час -- Результат: 14 EXTRACT(HOUR FROM created_at) AS order_hour, -- Извлекаем минуты -- Результат: 30 EXTRACT(MINUTE FROM created_at) AS order_minute, -- Извлекаем секунды -- Результат: 25 EXTRACT(SECOND FROM created_at) AS order_second, -- Извлекаем квартал года (1-4) -- Результат: 1 (первый квартал) EXTRACT(QUARTER FROM created_at) AS quarter, -- Извлекаем номер недели года (1-53) -- Результат: 11 EXTRACT(WEEK FROM created_at) AS week_number FROM orders WHERE id = 123; -- Для примера берём конкретную запись Завтра выложу вторую часть поста, где покажу работу с интервалами, вычисление дельт между датами и варианты форматирования дат. #SQL #Даты 📱 Подписаться на канал 💻 Курс автора по SQL DDL 🌎 Мой ИТ-стартап3,76%
3 окт. 2025 г.❗️ 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 department Cоздаёт столько групп, сколько уникальных значений в колонке department. Каждая такая группа — новая логическая единица, и к ней можно применять агрегатные функции, которые сводят множество строк к одному значению (например, средняя зарплата в отделе). ❗️ Почему WHERE не может работать с агрегатами? Потому что WHERE работает на уровне кортежей (строк), а не групп. Он отвечает на вопрос: «Оставить ли эту конкретную строку в результирующем наборе до группировки?». Агрегатные функции, напротив, не определены для одной строки — они требуют множества. Например, AVG(salary) для одной строки — это просто salary, но SQL не позволяет так делать в WHERE, чтобы избежать семантической неоднозначности. ❗️ Когда использовать HAVING? Используй HAVING, когда твоё условие зависит от результата агрегации по группе. ❗️ Примеры: ➖ «Отделы с более чем 10 сотрудниками» — HAVING COUNT(*) > 10 ➖ «Категории товаров, где общая выручка < 1000» — HAVING SUM(price * quantity) < 1000 ➖ «Пользователи, сделавшие хотя бы 3 заказа» — HAVING COUNT(order_id) >= 3 ❗️ Пример в коде: Найдём отделы, где средняя зарплата больше 70 000. SELECT department, AVG(salary) AS avg_salary FROM employees GROUP BY department HAVING AVG(salary) > 70000; Если попытаться написать это через WHERE — получим ошибку: WHERE AVG(salary) > 70000 -- СУБД заруинила запрос Потому что на этапе WHERE ещё нет групп, а значит — нет и средней зарплаты по отделу. ❗️ Итого Используй WHERE, если фильтруешь по конкретным значениям (например, status = 'active'). Используй HAVING, если фильтруешь по результатам агрегации (COUNT(*) > 5, AVG(price) < 100). #SQL #HAVING 📱 Подписаться на канал 💻 Курс автора по SQL DDL 🌎 Мой ИТ-стартап3,55%
31 дек.🥳Всех с наступающим! Решил подвести, итоги года для канала. Создавая его в феврале, я даже не думал, что получу такой крутой отклик от вас. Нас уже +1к, чему я безумно рад. 🏆 Хочу поблагодарить каждого подписчика за то, что читаете мой контент, ставите реакции, пишите коменты. Вы лучшие! 🍑Немного статистики: за этот год, было написано 115 постов, получено 1.8к реакций и 78.8к просмотров 🔥Посты с самым большим количеством реакций: ➖ Null в SQL — не "ничего", а неизвестно ➖ Having в SQL ➖ Junior-ready: выучить SQL и пройти собесы. Часть 1/2 🚀 От себя отмечу ещё пару постов: ➖Реляционная модель это не просто таблицы, это договор между людьми. — тут я немного ударился в философию данных, в следующем году планирую это активно продолжать 😂 ➖Он создал MySQL — и потерял миллиарды. История, о которой редко рассказывают — пост нового формата, потом написал ещё несколько таких, как по мне, читать чью-то историю это всегда интересно, ведь за любым ПО всегда стоят люди. ➖SQL Injection: как одна кавычка может взломать базу данных — ну тут все понятно 💻 На самом деле, ещё бы долго продолжал этот список, например, мне нравится серия постов про нормализацию данных или пока еще не полностью законченный обзор по работе с датами и временем Ещё мне забавно, было наблюдать за ростом качества контента, если первые посты были типовыми заметками, то последние стали вполне неплохими практическими рекомендациями или обзорами. В следующем году буду и дальше совершенствоваться в этом. Под конец года, писал довольно мало, из-за высокой нагрузки на работе, прочих проектах, в следующем году обещаю исправится, буду писать пост каждую неделю 😆 В общем, увидимся в 2026! 👍 📱 Подписаться на канал 💻 Курс автора по SQL DDL 🌎 Мой ИТ-стартап3,52%
10 мар. 2025 г.🗑 Удаление данных в SQL: основы DELETE Удаление данных — важная часть работы с БД. В SQL для этого используется оператор DELETE, который позволяет удалять конкретные строки в таблице. Разберем основные типы манипуляций по удалению с исходной таблицей employees (таблица в картинке поста) 1️⃣ Удаление всех строк DELETE FROM employees; ✔️ Удаляет все записи из таблицы. 🔹 Важно! Структура таблицы остается, но без данных. 2️⃣ Удаление с условием (WHERE) DELETE FROM employees WHERE position = 'Analyst'; ✔️ Удаляет только тех сотрудников, у кого position = 'Analyst'. После выполнения запроса строка 3 исходной таблицы (картинка в посте) исчезнет. 3️⃣ Удаление с подзапросом. Пост про вложенные запросы тут DELETE FROM employees WHERE id IN (SELECT id FROM employees WHERE salary < 55000); ✔️Удаляет всех, у кого зарплата меньше 55 000. 🔹 IN (SELECT ...) находит id подходящих строк перед удалением. 4️⃣ Удаление без удаления структуры ❌ DELETE не сбрасывает автоинкремент (AUTO_INCREMENT). ✔️ Если после DELETE добавить новую запись, её id не начнётся с 1, а продолжит счёт. Если нужно сбросить счётчик, используй: ALTER TABLE employees AUTO_INCREMENT = 1; ⚠️ Нужно учесть, что это изменит Id и других записей ⚠️ Когда использовать DELETE? ✅ Удаление отдельных строк по условию. ✅ Удаление с учетом зависимостей (FOREIGN KEY). Пост про внешние ключи тут ✅ Удаление с возможностью отката (ROLLBACK). ❌ Не использовать для полной очистки таблицы! Для этого есть TRUNCATE, но он относится к DDL и не поддерживает откат. 💡Курс от автора канала на Stepik с сертификатом "DDL в SQL: Определение и управление структурами баз данных" При переходе по данной ссылке скидка 50% #Операторы_и_работа_с_данными #SQL #DELETE #DML3,21%
16 сент. 2025 г.Привет, аналитики! Меня зовут Владимир Лунев. Более 5 лет я работаю в IT как бизнес- и системный аналитик. Я строил процессы и архитектуру реляционных баз данных для аналитиков, чтобы они могли быстро получить качественные данные, а не заниматься ручной обработкой исходной информации. Большую часть карьеры провёл в ритейле, где ежедневно принимаются решения на основе больших потоков данных: продаж, запасов, логистики, прогнозов спроса. Я часто сталкивался с задачами, где точность и скорость обработки данных имели критическое значение: приходилось быстро выявлять скрытые ошибки, обеспечивать корректность бизнес-отчётов и автоматизировать расчёты ключевых показателей. Несколько кейсов из моей работы: 👑 Оптимизировал отчёт и сократил время его выполнения с 3 часов, до 30 минут, не переписывая бизнес-логику, а разобрав EXPLAIN и исправив ошибки SQL-запросов. 👑 Построил систему контроля качества данных на основании проверочных скриптов, которая автоматически ловила дубли, NULL-ловушки и логические противоречия до попадания информации в отчёты. 👑 Разработал автоматизированный процесс агрегации и расчёта KPI для сети магазинов, позволивший ежедневно получать корректные метрики без ошибок. Я буду ведущим SQL-буткемпа — практикума, где вы получите реальные навыки, которые работают в боевых проектах бизнеса. В рамках буткемпа мы разберём: ➖Оптимизацию запросов в SQL — разбор EXPLAIN, выявление «тормозящих» мест, исправление лишних подзапросов и «фантомных» строк для ускорения критичных бизнес-отчётов и выгрузок. ➖Контроль качества данных — научимся писать кастомные скрипты проверок данных для точных и надёжных данных. ➖Прогнозы и тренды — построение когорт, скользящих метрик, lag/lead-анализ и простые линейные прогнозы для точного планирования. ➖Сценарный анализ «что если» — моделирование альтернатив через параметризацию, temp-таблицы и CTE, автоматизация расчётов для оценки влияния изменений на ключевые показатели. ➖ Агрегацию данных и полезные бизнес-метрики — расчёт growth, hitrate, долей, YoY, контроль перекосов и проведение A/B-анализов для оценки эффективности решений. ➖ Рекурсию и последовательности — поработаем с деревьями parent-child, обходом графов, кластеризацией и сегментацией пользовательских действий для глубокого анализа процессов. Формат: много практики на кейсах и задачах из IT-проектов и немного сопутствующей теории. Буткемп будет полезен аналитикам, data-engineers, backend-разработчикам, а также всем, кто работает с массивами данных, строит отчёты и хочет улучшить навыки владения SQL. Если вы хотите писать SQL-запросы так, чтобы данные реально работали на вас, а не наоборот — этот буткемп для вас! ➡️ Зарегистрироваться на буткемп по ранней цене 📊 Simulative3,15%
29 июл. 2025 г.🧊 Айсберг SQL Однажды, наткнулся на забавный мем, который с каждым уровнем становится все сложнее и страшнее, посмеялся и забыл. А недавно нашёл статью на Хабр и оказалось, что у мема есть реальное практическое применение, ведь он, по сути, этап за этапом разбирает взаимодействие через SQL с СУБД PostgreSQL, а автор мема SQL-разработчик Джордан Льюис. Так что можно использовать мем, чтобы выстроить свой путь изучения SQL, как методичку)) На этой неделе, кстати, опубликую пост, как быстро погрузиться в SQL, если вы новичок, и за пару недель (или меньше) достичь гордого уровня junior, минимально необходимого для прохождения собеседований.3,14%
25 февр. 2025 г.без подписи3,13%