SQL Ready | Базы Данных

🖥 Разберем ALTER — команда для изменения структуры таблиц! Добавить колонку, переименовать её, изменить тип или задать ограничение — всё это делается через ALTER TABLE. Один из важнейших инструментов в работе с готовыми таблицами. ➡️ SQL Ready | #шпора

Индексы по выражениям — ускоряем поиск по вычисляемым значениям! Обычный индекс работает только тогда, когда база может сравнить значение напрямую с колонкой. Если в условии WHERE применяется функция к полю, оптимизатор часто не может использовать обычный индекс. Таблица:

users(id, email)

Создадим индекс на email:

CREATE INDEX idx_users_email
ON users(email);

Теперь простой поиск по точному значению использует этот индекс:

SELECT *
FROM users
WHERE email = 'test@mail.com';

Но в реальных проектах часто нужна нормализация данных. Например, искать email без учёта регистра через LOWER():

SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';

Проблема в том, что PostgreSQL должен применить LOWER() к каждой строке, а потом сравнить результат. Обычный индекс по email для такого условия уже не подходит. Решение — создать индекс не на колонку, а на результат выражения:

CREATE INDEX idx_users_lower_email
ON users(LOWER(email));

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

EXPLAIN ANALYZE
SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';

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

CREATE INDEX idx_orders_year
ON orders(EXTRACT(YEAR FROM created_at));

Теперь запросы по этому выражению могут использовать индекс вместо полного прохода таблицы. Индекс нужно создавать под реальные запросы. Лишние увеличивают время INSERT/UPDATE и занимают место. 🔥 Индексы по выражениям полезны, когда одно и то же вычисление постоянно используется в WHERE, JOIN или ORDER BY. ➡️ SQL Ready | #практика

На Stepik запустили курс по вайбкодингу c Claude Code Первым делом вы освоите базу Claude Code и научитесь проектировать полноценные приложения. После этого перейдёте к более продвинутым инструментам и автоматизации: ➡️Разработаете собственные MCP-серверы и Claude Skills ➡️Автоматизируете разработку с помощью Agent Loops и хуков ➡️Освоите Claude Design, Cowork и Connectors ➡️Построите личную систему знаний на базе Obsidian + Claude Cowork ➡️Научитесь работать с таблицами при помощи Cowork ➡️Перестанете постоянно упираться в лимиты Claude А в финале получите готовую дорожную карту, полезные лайфхаки и 7 практических способов обхода блокировок Claude Code в России. 🔥 В течении 48 часов действует скидка 25%

🐱 Полезную статью нашёл на Хабре: «PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря»! В этой статье: • Рассматриваются возможности PostgreSQL, которые помогают решать типовые backend-задачи на уровне базы; • Разбираются эффективные инструменты для работы с очередями, запросами, индексами и поиском; • Показывается, как использовать встроенные механизмы PostgreSQL для повышения производительности приложений. 🔊 Продолжайте читать на Habr! ➡️ SQL Ready | #статья

📂 Напоминалка по SQL JOIN и объединению данных! Например, INNER JOIN возвращает только совпадающие записи, LEFT/RIGHT JOIN сохраняют данные одной из сторон, а FULL JOIN объединяет полный набор данных из обеих таблиц. Дополнительные проверки через NULL позволяют находить отсутствующие связи между сущностями. На картинке — основные типы JOIN и визуальное представление того, какие строки попадут в результат выполнения запроса. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Почему ROW_NUMBER(), RANK() и DENSE_RANK() в SQL дают разный результат! Есть такие оконные функции в SQL, которые выглядят почти одинаково, но используются для разных задач. ROW_NUMBER(), RANK() и DENSE_RANK() все умеют добавлять номера к строкам, но поведение меняется, когда в данных появляются одинаковые значения. На тестовых данных разница может быть незаметной. Но в реальных задачах это влияет на рейтинги пользователей, отчёты, аналитику и любые запросы, где важно правильное место записи. Например, есть таблица с результатами:

score
-----
100
100
90
80

Если нужно просто пронумеровать строки после сортировки, обычно используют ROW_NUMBER():

SELECT
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 2
90    | 3
80    | 4

ROW_NUMBER() всегда выдаёт уникальный номер для каждой строки. Даже если два значения одинаковые, они всё равно получат разные позиции. Это удобно, когда нужна обычная последовательная нумерация. Например, для пагинации, выбора последней записи из группы или получения одной строки после сортировки. Но для рейтингов такой вариант часто подходит не всегда. Если два пользователя набрали одинаковое количество баллов, обычно ожидается, что они займут одинаковое место. Для такой задачи используется RANK():

SELECT
    score,
    RANK() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 1
90    | 3
80    | 4

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

SELECT
    score,
    DENSE_RANK() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

Результат:

score | position
------+---------
100   | 1
100   | 1
90    | 2
80    | 3

DENSE_RANK() работает похоже на RANK(), но продолжает нумерацию без пропусков. Получается простое правило: ROW_NUMBER() — когда каждая строка должна получить свой уникальный номер; RANK() — когда одинаковые значения должны иметь одинаковое место, а пропуски после них допустимы; DENSE_RANK() — когда одинаковые значения должны иметь одинаковое место, но нумерация должна идти без пропусков. Есть ещё один практический момент, который часто забывают при использовании ROW_NUMBER(). Если несколько строк имеют одинаковое значение для сортировки:

SELECT
    id,
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC
    ) AS position
FROM results;

то порядок таких строк может быть нестабильным. База данных не обязана всегда возвращать их в одинаковой последовательности. Поэтому в реальных проектах часто добавляют дополнительное поле для сортировки:

SELECT
    id,
    score,
    ROW_NUMBER() OVER (
        ORDER BY score DESC, id
    ) AS position
FROM results;

🔥 ROW_NUMBER(), RANK() и DENSE_RANK() решают похожую задачу, но предназначены для разных сценариев. Главное — понимать, нужна ли вам обычная нумерация строк или именно логика рейтинга. ➡️ SQL Ready | #практика

Опа, тут бывший сеньор одного из IT-отделов Яндекса Игорь Никитин выкатил целый канал про Python — и это лучшее, что есть в рунете по теме. Качественные гайды. Советы от известных прогеров. Тематические мемасы. Короче, ничего лишнего. Хватит душить питона, учись его кодить: https://t.me/+IzIPzvoa7p40ZTUy 🐍

🤔 Learn PostgreSQL — информативное руководство! Этот репозиторий поможет разобраться с PostgreSQL с нуля и понять, как работать с базой данных на практике. Здесь простым языком объясняются SQL-запросы, создание таблиц, связи между ними, индексы, объединения, агрегатные функции и др. Материал построен последовательно и с большим количеством примеров.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

✍️ PostgreSQL Wiki — справочник и документация по PostgreSQL! На сайте опубликованы статьи, руководства, инструкции и практические материалы по работе с одной из самых популярных СУБД. Здесь можно найти информацию по установке, настройке, администрированию, оптимизации производительности, репликации, резервному копированию, расширениям и др. 📌 Оставляю ссылочку: wiki.postgresql.org ➡️ SQL Ready | #ресурс

Используй RETURNING как временную таблицу! Многие после UPDATE делают отдельный SELECT, чтобы получить изменённые данные. Но PostgreSQL уже умеет вернуть результат изменения через RETURNING.

UPDATE orders
SET status = 'paid',
    paid_at = now()
WHERE id = 1001
RETURNING id, status, paid_at;

Один запрос вместо двух. RETURNING можно сразу передавать дальше. Например, обновили заказ и сразу записали историю изменения:

WITH changed AS (
    UPDATE orders
    SET status = 'cancelled'
    WHERE id = 1001
    RETURNING id, status
)
INSERT INTO order_history(order_id, new_status)
SELECT id, status
FROM changed;

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

WITH moved AS (
    DELETE FROM queue
    WHERE id = 55
    RETURNING *
)
INSERT INTO archive_queue
SELECT *
FROM moved;

🔥 Получается "забрать строку и положить в другую таблицу" одной транзакционной операцией. Часто заменяет сложный код в сервисах и убирает лишние запросы к базе. ➡️ SQL Ready | #совет

🇷🇺 Разбираешься в радиочипах, оптике и связи? Забери до 1 000 000 рублей за свои инженерные навыки на турнире «Дронкон» 🇷🇺 «Сталинские Соколы» открывают регистрацию на 4-й Всероссийский турнир «Дронкон», который пройдет с 22 по 26 августа. Турнир пройдет по направлению: - Инженерное дело: навыки программирования, сборка электронного оборудования, беспроводная связь, оптические системы + стратегия «Битва Дронов»; Призовой фонд для победителей:

🥇место – 1 000 000 рублей 🥈место – 700 000 рублей 🥉место – 500 000 рублей Награда за 4-8 места - 100 000 рублей

Пройди заочный онлайн-этап и получи путевку на очный этап турнира в Республику Татарстан! Перелет, питание, проживание - за счет организаторов. 🇷🇺 Подать заявку и узнать подробности 🇷🇺

Почему CONCAT_WS в PostgreSQL часто лучше обычной конкатенации строк! Есть такие SQL-функции, которые вроде бы выглядят слишком простыми, чтобы о них писать отдельный пост. Но именно они часто убирают кучу мелких проблем в реальных проектах, CONCAT_WS — хороший пример. Когда работаешь с тестовыми данными, кажется, что собрать строку очень просто. Есть имя, фамилия, отчество — соединяем их через пробел и получаем красивый результат. Обычно первый вариант выглядит так:

SELECT
    first_name || ' ' || middle_name || ' ' || last_name AS full_name
FROM users;

На первый взгляд всё нормально. Но потом база начинает жить настоящими данными. У одного пользователя нет отчества. У другого не заполнена фамилия. После миграции часть полей приходит пустыми. И вот здесь простой запрос начинает вести себя не так, как ожидает разработчик. Например:

first_name = 'John'
middle_name = NULL
last_name = 'Smith'

Кажется логичным получить:

John Smith

Но PostgreSQL вернёт:

NULL

Причина в том, что NULL — это не пустое значение. Это отсутствие значения. При обычной конкатенации строк неизвестная часть делает неизвестным весь результат. Конечно, можно начать добавлять COALESCE:

SELECT
    first_name || ' ' ||
    COALESCE(middle_name || ' ', '') ||
    last_name
FROM users;

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

SELECT
    CONCAT_WS(
        ' ',
        first_name,
        middle_name,
        last_name
    ) AS full_name
FROM users;

CONCAT_WS расшифровывается как "concatenate with separator". Первый аргумент — разделитель, который нужно использовать между значениями. Главная особенность в том, что функция сама пропускает NULL. То есть:

John + NULL + Smith

превратится в:

John Smith

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

Germany, Berlin, Alexanderplatz 10

может состоять из нескольких частей, но квартира или дополнительный номер могут отсутствовать. Не хочется писать отдельные проверки для каждого поля только ради красивого вывода. Но есть нюанс, который часто забывают. CONCAT_WS пропускает NULL, но пустую строку считает настоящим значением. Например, после загрузки данных из CSV можно получить:

middle_name = ''

Для пользователя это выглядит так же, как отсутствие значения. Но PostgreSQL различает эти случаи. В результате можно получить: John Smith с двойным пробелом. Поэтому в системах, где данные приходят из разных источников, часто сначала нормализуют значения:

NULLIF(middle_name, '')

После этого пустые строки становятся NULL, и CONCAT_WS уже работает предсказуемо. На небольших примерах это кажется мелочью. Но когда у тебя несколько миллионов записей и данные собираются из разных сервисов, именно такие детали начинают влиять на качество данных и количество лишнего кода. 🔥 CONCAT_WS — хороший пример того, как правильный инструмент делает SQL проще. Если нужно собрать строку из нескольких необязательных полей — часто лучше использовать её, чем вручную обрабатывать каждый NULL. ➡️ SQL Ready | #практика

Пачку офферов заказывали? О всех трудоустройствах через ИИ-ассистента Софи ребята узнают от пользователей. И какой же кайф, когда они делятся своими историями. Вот так в чате узнали сразу о трех новых офферах: • Кейс Сергея - 2 недели в Софи и 2 оффера. • Кейс Елены - 1 неделя в Софи и оффер спустя 10 лет перерыва в работе. Елене 52 года. • Кейс Юлии - 1 месяц в Софи, свитчер из финансового аналитика в разработчика SQL. И еще один оффер🎉 Искренние поздравления ребятам и удачи им на новой работе! В следующий раз доступ в Софи откроется уже 21 июля. Если хочешь получить 3 дня бесплатного доступа - подписывайся на этот канал, все анонсы будут там.

📂 Напоминалка по шардингу данных! Например, range-based шардинг делит данные по диапазонам значений, hash-based — распределяет записи через хэш-функцию, а consistent hashing помогает минимизировать перераспределение данных при добавлении новых нод. На картинке — 4 алгоритма шардинга, которые полезно знать при проектировании масштабируемых систем и высоконагруженных баз данных. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Обычное сравнение через = и != ломается, как только появляется NULL!

old_value IS DISTINCT FROM new_value

В SQL NULL никогда не равен даже другому NULL, поэтому сравнение начинает вести себя не так, как ожидается.

SELECT
    NULL = NULL,
    NULL != NULL;

Оба выражения вернут не TRUE и не FALSE, а NULL. Именно из-за этого часто ломается логика сравнения.

SELECT *
FROM users
WHERE old_email != new_email;

Кажется, что запрос покажет все изменённые email. Но если одно из значений NULL, строка может просто не попасть в выборку. Для таких случаев в PostgreSQL есть специальный оператор.

SELECT *
FROM users
WHERE old_email IS DISTINCT FROM new_email;

Теперь NULL корректно участвует в сравнении. PostgreSQL считает NULL обычным сравниваемым состоянием.

NULL IS DISTINCT FROM NULL        -- false
NULL IS DISTINCT FROM 'test'      -- true
'a'  IS DISTINCT FROM 'b'         -- true

Пригодится в аудитах изменений, UPSERT-логике, ETL и триггерах, где важно понять: значение реально изменилось или нет. 🔥 Оператор, который убирает большое количество багов при работе с NULL. ➡️ SQL Ready | #совет

IT мероприятия 🤘 Всё самое интересное для карьеры в IT: митапы, хакатоны, конференции, стажировки и обучение. Подписывайся 🤘 1. Москва 2. Санкт-Петербург 3. Для стажеров и студентов

📂 Напоминалка по генерации уникальных ID в SQL и распределённых системах! Например, Auto-Increment подходит для простых SQL-проектов, где одна база данных управляет последовательностью записей, а Snowflake/UUID чаще используют в высоконагруженных системах с микросервисами, где требуется генерация ID без единой точки отказа. На картинке — 5 основных подходов к созданию уникальных идентификаторов. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

👍 Годная статья вышла на Хабре: «Шардированный не значит распределённый, что важно знать, когда PostgreSQL становится мало»! В этой статье: • Объясняется разница между шардированным PostgreSQL и настоящими распределёнными СУБД; • Разбирается, почему Citus и похожие решения не дают полноценные ACID-гарантии для multi-shard транзакций; • Показывается, как работают 2PC, distributed snapshot и уровни изоляции транзакций; • На примерах объясняются проблемы consistency и eventual consistency в распределённых системах;

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

DEFERRABLE constraints — проверяй связи в конце транзакции, а не после каждой строки! Иногда данные нужно вставить в несколько связанных таблиц внутри одной транзакции, но порядок операций временно нарушает внешний ключ.

BEGIN;

INSERT INTO payments (id, order_id)
VALUES (1, 100);

INSERT INTO orders (id)
VALUES (100);

COMMIT;

Обычный FOREIGN KEY проверяется сразу, поэтому первый INSERT упадёт, если заказа 100 ещё нет. DEFERRABLE INITIALLY DEFERRED переносит проверку ограничения на момент COMMIT, поэтому база смотрит не на промежуточное состояние, а на итог транзакции.

SET CONSTRAINTS ALL IMMEDIATE;

При необходимости проверку можно принудительно выполнить раньше прямо внутри транзакции. Это полезно при сложных импортах, циклических связях, миграциях и переносе данных между системами, где временный неправильный порядок вставки допустим, но финальное состояние должно быть строго консистентным. 🔥 Фишка в том, что ты не отключаешь целостность данных, а просто переносишь момент проверки. ➡️ SQL Ready | #совет

1000+ свежих IT-вакансий каждый месяц в одном месте 🤘 Пока другие листают hh — мы ищем вакансии по всему рынку: каналы, сайты компаний, стартапы и закрытые источники. IT Россия IT СНГ Стажировки Digital Международка Удалёнка Python Бигтех Дизайн QA Джунам Frontend Аналитика Стартапы за рубежом DevOps Не с HH Автоотклики