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

🖥 MySQL — работа с NULL! Шпаргалка по обработке NULL в MySQL: подстановка резервных значений, проверка наличия и отсутствия данных, условная обработка, безопасные вычисления и сравнение nullable-значений. Помогает учитывать семантику NULL и избегать неочевидного поведения в условиях, выражениях и вычислениях. ➡️ SQL Ready | #шпора

Почему ctid нельзя использовать как постоянный идентификатор! В PostgreSQL каждая строка имеет системную колонку ctid. Она содержит физический адрес текущей версии строки в таблице: номер страницы и позицию строки внутри этой страницы. Иногда ctid используют для поиска, удаления или диагностики отдельных записей, но важно понимать, что это не постоянный идентификатор строки. Значение ctid может измениться в процессе обычной работы базы данных, поэтому использовать его в прикладной логике нельзя. Для начала создадим простую таблицу с первичным ключом и несколькими тестовыми записями, чтобы наглядно проследить, как изменяется значение ctid.

CREATE TABLE users (
    id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name TEXT
);

Теперь добавим несколько строк, с которыми будем работать в дальнейших примерах.

INSERT INTO users (name)
VALUES
('Alice'),
('Bob'),
('Charlie');

Посмотрим, какое значение ctid PostgreSQL присвоил каждой записи после вставки.

SELECT
    ctid,
    id,
    name
FROM users;

Результат может выглядеть так:

ctid  | id | name
------+----+--------
(0,1) | 1  | Alice
(0,2) | 2  | Bob
(0,3) | 3  | Charlie

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

UPDATE users
SET name = 'Robert'
WHERE id = 2;

После выполнения UPDATE снова посмотрим значения ctid и сравним их с предыдущим результатом.

SELECT
    ctid,
    id,
    name
FROM users;

Теперь можно увидеть, что значение ctid изменилось. Например:

ctid  | id | name
------+----+---------
(0,1) | 1  | Alice
(0,4) | 2  | Robert
(0,3) | 3  | Charlie

Это происходит из-за механизма MVCC. При выполнении UPDATE PostgreSQL не изменяет строку на месте, а создаёт её новую версию, которая получает новый физический адрес (ctid). Старая версия строки некоторое время остаётся в таблице и может быть видима другим транзакциям в зависимости от их снимка данных. Изменение ctid происходит не только при UPDATE. Любые операции, которые физически переписывают таблицу, также приводят к изменению физических адресов строк. Например:

VACUUM FULL users;

или

CLUSTER users USING users_pkey;

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

CREATE TABLE duplicate_users (
    name TEXT
);

Добавим одинаковые строки:

INSERT INTO duplicate_users (name)
VALUES
('Alice'),
('Alice'),
('Bob');

Удалим только одну из двух одинаковых строк:

DELETE
FROM duplicate_users
WHERE ctid = (
    SELECT ctid
    FROM duplicate_users
    WHERE name = 'Alice'
    LIMIT 1
);

В результате останется одна строка с именем Alice. В этом примере ctid определяется и используется в рамках одного SQL-запроса, поэтому используется актуальный физический адрес версии строки и не возникает проблемы с использованием устаревшего значения. 🔥 ctid — это физический адрес текущей версии строки, а не её постоянный идентификатор. Для связи данных всегда используйте первичный ключ, а ctid оставьте для диагностических и служебных операций. ➡️ SQL Ready | #практика

7,2 млн рублей призового фонда и реальные задачи космической отрасли 🚀 В сентябре пройдет серия КосмоХакатонов для студентов, молодых ученых и специалистов. Участникам предстоит за два дня разработать собственное решение, поработать с экспертами и представить проект жюри. Участников ждут: 🛰 реальные задачи космической отрасли 👥 команды от 3 до 5 человек 💻 очный и онлайн-форматы 🧑‍💻 работа с экспертами и трекерами 🏆 финал в Москве Первый КосмоХакатон стартует уже 4 сентября в Ростове-на-Дону. Дальше серия продолжится в Красноярске, Нижнем Новгороде, Благовещенске и Санкт-Петербурге, а завершится финалом в Москве. Участие бесплатное. Присоединиться могут студенты, аспиранты, молодые ученые и специалисты от 18 лет. 🔗 Зарегистрироваться: https://космохакатон.рф

🐱 Нашел крайне занимательную статью на Хабре: «Условная агрегация в SQL: ускоряем отчеты, избавляясь от лишних JOIN-ов и подзапросов»! В этой статье: • Узнаете, как ускорять сложные SQL-запросы с помощью условной агрегации; • Разберёте применение CASE и FILTER вместо множества подзапросов и JOIN-ов; • Посмотрите на примерах, как сделать SQL-код быстрее, чище и проще для поддержки.

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

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

✍️ Архитектура высоконагруженных систем — подробный материал по проектированию Highload! Здесь разобраны ключевые вещи, с которыми сталкиваются при разработке нагруженных систем: RPS, latency и throughput, вертикальное и горизонтальное масштабирование, индексы, репликация и шардирование баз данных, кеширование, брокеры сообщений и др. Есть практические примеры с MySQL, PostgreSQL, Kafka и Tarantool, а также инструменты для тестирования и мониторинга.

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

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

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

SELECT
    u.id,
    u.name,
    (
        SELECT SUM(o.amount)
        FROM orders o
        WHERE o.user_id = u.id
    ) AS total_amount
FROM users u;

Если users содержит миллион строк, подзапрос потенциально может быть выполнен миллион раз. Даже при наличии индекса по orders.user_id такой подход иногда становится менее эффективным, особенно в сложных отчётах. Часто можно сначала агрегировать данные, а затем присоединить результат:

SELECT
    u.id,
    u.name,
    COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
    SELECT
        user_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY user_id
) o
ON o.user_id = u.id;

Здесь агрегация выполняется один раз, после чего результат соединяется с таблицей пользователей. Но это не универсальное правило. Современные оптимизаторы умеют преобразовывать некоторые коррелированные подзапросы в более эффективные планы выполнения, поэтому всегда нужно смотреть реальный план через EXPLAIN / EXPLAIN ANALYZE. Для получения последнего заказа пользователя часто используют оконные функции:

SELECT
    user_id,
    created_at
FROM (
    SELECT
        user_id,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM orders
) t
WHERE rn = 1;

Но и здесь нет универсального решения. При правильном индексе, например:

(user_id, created_at DESC)

коррелированный запрос вида:

SELECT ...
FROM orders
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 1;

может быть быстрее, потому что база сможет быстро найти одну нужную строку через индекс. Делаем вывод: коррелированные подзапросы сами по себе не являются ошибкой. Они могут быть как хорошим решением, так и причиной проблем с производительностью — всё зависит от данных, индексов и выбранного плана выполнения. 🔥 В больших отчётах и высоконагруженных API всегда проверяйте фактический план выполнения. Иногда JOIN, предварительная агрегация или оконные функции позволяют значительно уменьшить количество лишних операций. ➡️ SQL Ready | #практика

Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами. И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную. Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 60 тысяч: @vibecoding_tg

📂 Шпаргалка по Backend-разработке! Например, REST используется для построения API, Redis помогает кэшировать данные, а Docker позволяет упаковать приложение вместе со всеми его зависимостями. На картинке — основные направления Backend-разработки: языки программирования, базы данных, API, авторизация, серверы, контейнеризация, CI/CD и мониторинг. Полезная карта того, что стоит изучить Backend-разработчику. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Научите оптимизатор понимать ваши данные! PostgreSQL по умолчанию считает, что значения в разных колонках независимы друг от друга. Но в реальных данных это часто не так. Например, если city = 'Paris', то country почти всегда будет 'France'. Без этой информации оптимизатор может сильно ошибиться при оценке количества строк и выбрать неудачный план.

EXPLAIN
SELECT *
FROM users
WHERE country = 'France'
  AND city = 'Paris';

Вместо того чтобы сразу создавать новый индекс, попробуйте расширенную статистику.

CREATE STATISTICS users_dep (dependencies)
ON country, city
FROM users;

ANALYZE users;

После ANALYZE PostgreSQL сможет учитывать зависимость между колонками и точнее оценивать селективность условий. Во многих случаях этого достаточно, чтобы оптимизатор выбрал более эффективный план выполнения. 🔥 Если запрос фильтрует по нескольким связанным колонкам и оптимизатор ошибается в оценке, сначала попробуйте CREATE STATISTICS, а уже потом решайте, нужен ли новый индекс. ➡️ SQL Ready | #совет

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку Окружение решает больше, чем кажется. Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре. AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Хакинг: t.me/linuxkalii ВАЙБКОДИНГ: t.me/data_analysis_ml DevOps: t.me/DevOPSitsec Docker: https://t.me/+90Z5TAyfuNU5YmRi Golang: t.me/Golang_google Rust: t.me/rust_code C++: t.me/cpluspluc C#: t.me/csharp_1001_notes Java: t.me/javatg JavaScript: t.me/javascriptv React: t.me/react_tg PHP: t.me/phpshka Android: t.me/android_its Мобильная разработка: t.me/mobdevelop Базы данных: t.me/sqlhub Big Data: t.me/bigdatai Математика: t.me/data_math Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка Frontend: https://t.me/addlist/mzMMG3RPZhY2M2Iy ИТ-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Max Ai: https://max.ru/ai_machinelearning_big_data Max python: https://max.ru/pythonl ТЕХНО: https://max.ru/vistehno Max Go: https://max.ru/Golang_google Max Linux: https://max.ru/linuxkalii Devops: https://max.ru/DevOPSitsec C#: https://max.ru/csharp_ci C++: https://max.ru/cpluspluc SQL: https://max.ru/sqlhub Java: https://max.ru/javatg Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

🤔 SQL Lab — интерактивная платформа для изучения и практики SQL! Сайт для тех, кто хочет освоить SQL через работу с запросами. Код пишется прямо в браузере: выполняете запрос, сразу видите результат и получаете автоматическую проверку решения. Обучение построено от базовых SELECT и ORDER BY до JOIN, подзапросов, транзакций, индексов, оптимизации запросов и PostgreSQL. Есть структурированные курсы с теорией и практикой. 📌 Оставляю ссылочку: sqllab.ru ➡️ SQL Ready | #ресурс

UNIQUE и NULL в PostgreSQL 15! До PostgreSQL 15 уникальные ограничения считали NULL разными значениями. Это означало, что таблица спокойно принимала сколько угодно строк с NULL, даже если на колонке стоял UNIQUE.

CREATE TABLE users (
    email text UNIQUE
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Обе вставки выполнятся успешно. Если NULL тоже должен быть уникальным, приходилось придумывать обходные пути. Кто-то делал частичные индексы, кто-то использовал COALESCE(), кто-то заводил отдельные флаги.

CREATE TABLE users (
    email text,
    CONSTRAINT users_email_key
        UNIQUE NULLS NOT DISTINCT (email)
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Вторая вставка уже завершится ошибкой. Для ограничения NULL считается таким же значением, как и любой другой ключ.

CREATE TABLE users (
    tenant_id int,
    email text,
    CONSTRAINT uq_user
        UNIQUE NULLS NOT DISTINCT (tenant_id, email)
);

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

+85.000р. получил в январе +141.000р. пришло в июне +187.000р. получил в июле Согласись, похоже на цифры с потолка. Но так сейчас зарабатывает Андрей Д. на запуске контент-заводов для бизнеса. В 2026 бизнес по всей РФ начал активно внедрять ИИ, чтобы автоматизировать создание текстов, видео и фото для соцсетей и маркетплейсов. Такие ИИ настраивает Евгений Андрианов с командой. Андрей присоединился к команде Евгения и за пару недель с нуля научился работать с ИИ. На старте он заработал 85 тыс., а сейчас вышел на более 180 тыс в месяц. Как это работает: - Проходишь обучение пару недель; - Получаешь реальный заказ из базы; - Собираешь ИИ-контент-завод по формуле; - Сдаёшь проект — получаешь деньги. Объём работом выбираешь сам. График свободный. Средний доход участников команды — 92 852р. в месяц. Не нужно искать клиентов самостоятельно. Не нужен опыт. Не требуется техническое образование. Всё, что нужно для старта — запустить вводный инструктаж на сайте бесплатно. Осталось 14 мест. 👉 Пробуй Реклама. ООО "АИМ" ИНН 9723249701

❤️ Интересная статья на Хабре: «Что такое RAGFlow и с чем его едят»! В этой статье: • Разберётесь, как RAGFlow помогает LLM работать с внутренними документами и снижать количество галлюцинаций; • Узнаете, чем RAGFlow отличается от классического RAG и как он обрабатывает PDF, таблицы, схемы и сканы; • Посмотрите, как развернуть RAGFlow и использовать его для баз знаний, техподдержки и аналитики.

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

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

📂 Шпаргалка по нормализации баз данных в MySQL! Например, 1NF требует атомарных значений, 2NF избавляет от частичных зависимостей, а 3NF — от транзитивных. Для более сложных схем пригодятся BCNF и 4NF. На картинке — основные нормальные формы с требованиями, примерами и пользой каждой из них. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

🖥 PostgreSQL — блокировки строк и конкурентный доступ! Шпаргалка по механизмам синхронизации параллельных транзакций в PostgreSQL: защита строк от конкурентных изменений и удаления, управление ожиданием и пропуском занятых строк, явная блокировка таблиц и диагностика ожидающих блокировок. Помогает контролировать конкурентный доступ и корректно реализовывать транзакционные сценарии. ➡️ SQL Ready | #шпора

👨‍💻 Junior Database — база вопросов и ответов по SQL и базам данных! В репозитории собраны 27 тем, которые часто встречаются при изучении баз данных и подготовке к техническим собеседованиям: транзакции и ACID, нормализация и денормализация, первичные и внешние ключи, JOIN, GROUP BY и HAVING, индексы, миграции, хранимые процедуры и триггеры. Также затрагиваются оптимизация запросов, партицирование, репликация, шардинг и различия между SQL и NoSQL. Оставляю ссылочку: GitHub 📱 ➡️ SQL Ready | #репозиторий

📂 SQL в одной шпаргалке! Например, SELECT, WHERE и ORDER BY отвечают за выборку, фильтрацию и сортировку данных, JOIN связывает таблицы, а GROUP BY, агрегатные и оконные функции помогают анализировать результаты запросов. На картинке — структурированная карта SQL: от базовых запросов и объединения таблиц до CTE, подзапросов, DDL/DML/DCL/TCL, транзакций и ограничений целостности данных. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Работайте с периодами как с одним значением! Когда у записи есть start_at и end_at, проверки пересечений быстро превращаются в набор сравнений. В PostgreSQL для этого есть range types: например, tstzrange для диапазона timestamptz. Вместо:

WHERE start_at < :end_at
  AND end_at > :start_at

можно явно работать с диапазонами:

WHERE tstzrange(start_at, end_at, '[)')
   && tstzrange(:start_at, :end_at, '[)')

Оператор && означает «диапазоны пересекаются». [) задаёт полуинтервал: начало включено, конец исключён, поэтому встреча до 12:00 и следующая с 12:00 не считаются пересекающимися. Но интереснее то, что PostgreSQL умеет проверять диапазоны и другими операторами:

period @> now()       -- содержит момент времени
period && :period     -- пересекается
period <@ :period     -- находится внутри

Если такие проверки выполняются постоянно, диапазон можно хранить непосредственно в таблице и индексировать GiST:

CREATE INDEX bookings_period_idx
ON bookings USING gist (period);

И самое полезное: правило «для одной комнаты интервалы не должны пересекаться» можно перенести из приложения непосредственно в БД:

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE bookings
ADD CONSTRAINT bookings_no_overlap
EXCLUDE USING gist (
    room_id WITH =,
    period  WITH &&
);

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