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

👍 PingCAP Talent Plan — практический курс по разработке системного уровня! Этот репозиторий содержит учебные материалы и практические задания по разработке высоконагруженных систем. Основной фокус — внутреннее устройство баз данных, распределённые системы, хранение данных, производительность и инженерные подходы, которые используются в реальных проектах. Оставляю ссылочку: GitHub 📱 ➡️ SQL Ready | #репозиторий

📂 MySQL JOIN: шпаргалка по объединению таблиц! Разобраны способы объединения таблиц, получение связанных данных, поиск совпадающих и отсутствующих записей, а также использование EXISTS и NOT EXISTS для проверки связей между таблицами. На картинке — основные типы JOIN в MySQL с примерами SQL-запросов и визуальным объяснением. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

🤔 DBA1 — материалы по администрированию PostgreSQL и базам данных! Сайт посвящён изучению PostgreSQL и администрированию баз данных. Здесь собраны учебные материалы по установке и настройке PostgreSQL, работе с сервером, архитектуре СУБД, управлению пользователями, резервному копированию, репликации и другим задачам, с которыми сталкиваются DBA и backend-разработчики. 📌 Оставляю ссылочку: dba1.ru ➡️ SQL Ready | #ресурс

Старые и новые значения в RETURNING! До PostgreSQL 18 RETURNING не позволял получить одновременно старое и новое состояние строки. Если нужно было сравнить значения до и после UPDATE, приходилось писать CTE или выполнять дополнительный запрос.

WITH old_data AS (
    SELECT id, price
    FROM products
    WHERE category = 'books'
)
UPDATE products p
SET price = p.price * 1.1
FROM old_data o
WHERE p.id = o.id
RETURNING
    o.price AS old_price,
    p.price AS new_price;

В PostgreSQL 18 старые и новые значения доступны прямо внутри RETURNING.

UPDATE products
SET price = price * 1.1
WHERE category = 'books'
RETURNING
    id,
    old.price AS old_price,
    new.price AS new_price;

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

DELETE FROM products
WHERE discontinued
RETURNING
    old.id,
    old.name,
    old.price;

Та же идея работает и для DELETE: старое состояние строки доступно напрямую через old. 🔥 Небольшое изменение PostgreSQL 18, которое избавляет от лишних CTE и делает RETURNING заметно полезнее. ➡️ SQL Ready | #совет

Wuldi Hosting // Deployment Ready 🚀 🔥 Скидка 40% на мощные VPS/VDS для разработчиков! 🔥 Разворачивайте свои базы данных, Telegram-ботов, бэкенд и Docker-контейнеры на сверхбыстрых серверах в проверенных дата-центрах Европы. Идеально подходит под Highload-проекты, продакшн и пет-проекты. 🤖 Запустить бота (купить в 1 клик): autobuy_bot 🌐 Наш сайт: Wuldi.com ⚙️ Инфраструктура и Спеки: • hardware: Топовое железо AMD Epyc 9454 / Ryzen 9950x • net_speed: Аплинки до 10 Гбит/с • uptime_rate: Честный 99.97% • privacy_level: 100% анонимность при регистрации 👤 Dev_contacts: • tech_support: @wuldisupportbot • root_admin: @Flameochka 👇 Забирайте конфигурацию со скидкой 40% прямо в боте!

📂 Roadmap по изучению SQL для разработчиков и аналитиков! На картинке — путь изучения SQL: от основ устройства базы данных и типов данных до запросов, операторов, функций, транзакций и управления доступом. Собраны основные темы, которые стоит пройти: структура базы данных и объекты, команды работы с данными (DDL, DML, DQL, DCL, TCL), построение запросов, операторы, функции, типы данных и др. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Почему JSONB в PostgreSQL не всегда быстрее JSON! В PostgreSQL тип JSONB часто выбирают вместо JSON из-за возможности индексации и работы с операторами поиска. Но отличие между ними не только в скорости чтения — оно связано с тем, как PostgreSQL хранит, обрабатывает и изменяет данные. Рассмотрим таблицу с JSONB-структурой:

CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    payload JSONB
);

Добавим документ с вложенными данными:

INSERT INTO events (payload)
VALUES (
    '{
        "user": {
            "id": 100,
            "role": "admin"
        },
        "active": true
    }'
);

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

SELECT *
FROM events
WHERE payload @> '{"active": true}';

Оператор @> проверяет наличие указанного фрагмента внутри JSONB-объекта. Для ускорения подобных запросов используется GIN-индекс:

CREATE INDEX idx_events_payload
ON events
USING GIN (payload);

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

UPDATE events
SET payload = jsonb_set(
    payload,
    '{user,role}',
    '"moderator"'
)
WHERE id = 1;

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

SELECT '{"b":2,"a":1}'::json;

В этом случае исходный порядок ключей сохраняется. JSONB хранит уже разобранную структуру документа:

SELECT '{"b":2,"a":1}'::jsonb;

В JSONB порядок ключей не сохраняется, поскольку PostgreSQL работает с внутренним структурированным представлением данных. Поэтому он лучше подходит для случаев, когда требуется поиск, индексация и работа с содержимым документа, а JSON — когда важно сохранить исходное представление данных. Отдельно стоит учитывать особенности работы индексов. Например, запрос с извлечением значения через оператор ->> выглядит следующим образом:

SELECT *
FROM events
WHERE payload->>'active' = 'true';

А запрос с проверкой содержимого JSONB-объекта использует другой механизм доступа:

SELECT *
FROM events
WHERE payload @> '{"active": true}';

GIN-индекс эффективно работает с операторами JSONB, такими как проверка вхождения @>, проверка существования ключей ?, а также операторы проверки нескольких ключей ?| и ?&. Однако GIN-индекс не ускоряет автоматически любые выражения с извлечением значений через ->>. Для таких случаев могут использоваться отдельные функциональные индексы. Например, индекс для конкретного поля JSONB можно создать следующим образом:

CREATE INDEX idx_events_active
ON events ((payload->>'active'));

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

Замечал странную штуку: дел не так уж много, но любое – как будто через сопротивление? Не то чтобы лень. Просто не делается и все тут! Зато видосики на Ютубе залетают на ура... Попался годный разбор, советую посмотреть, если тоже чувствуешь, что превращаешься в апатичного зомби 👉🏼 https://t.me/Manifestans Мысль, которая зашла: когда перестаешь понимать "чего хочу Я", даже нормальная жизнь ощущается, как каторга. Кликай сюда, чтобы разобраться, что с тобой происходит и как снова начать испытывать ощущение, что ты живешь, а не существуешь.

📂 Напоминалка по порядку выполнения SQL-запросов! Например, разработчик пишет запрос начиная с SELECT, но SQL-движок выполняет его иначе: сначала формирует источник данных через FROM, объединяет таблицы через JOIN, фильтрует записи через WHERE, группирует данные через GROUP BY и только после этого формирует итоговый результат. На картинке — логический порядок выполнения SQL-операций. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

IS DISTINCT FROM — сравнение значений с NULL! NULL обозначает отсутствие известного значения, поэтому стандартные операторы сравнения = и <> не позволяют корректно определить равенство или различие, если один из операндов содержит NULL. Например:

NULL <> 'new value'

Результатом выражения будет NULL, а не TRUE или FALSE. Это связано с трёхзначной логикой SQL: результат сравнения с неизвестным значением также является неизвестным. Поэтому проверки изменения данных с использованием обычных операторов сравнения требуют дополнительной обработки:

column <> new_value
OR (column IS NULL AND new_value IS NOT NULL)
OR (column IS NOT NULL AND new_value IS NULL)

Оператор IS DISTINCT FROM решает эту задачу, выполняя сравнение с явным учетом NULL и всегда возвращая логическое значение. Пример обновления пользователя только при фактическом изменении email:

UPDATE users
SET email = :new_email
WHERE id = :id
  AND email IS DISTINCT FROM :new_email;

Если значения совпадают, строка обновлена не будет. Если одно значение содержит NULL, а другое — данные, оператор определит их как различные. Оператор также корректно обрабатывает случай, когда оба значения равны NULL:

SELECT NULL IS DISTINCT FROM NULL;

Результат:

false

В логике IS DISTINCT FROM два значения NULL считаются одинаковыми, так как оба представляют отсутствие значения. Без использования данного оператора аналогичная проверка требует дополнительных условий:

email <> :new_email
OR (email IS NULL AND :new_email IS NOT NULL)
OR (email IS NOT NULL AND :new_email IS NULL)

IS DISTINCT FROM заменяет такую конструкцию одним выражением и делает сравнение nullable-полей более предсказуемым. При обновлении сущностей через API, синхронизации данных и импорте часто возникает ситуация, когда передаётся полный объект, хотя часть полей не изменилась. Обычный запрос:

UPDATE users
SET
    email = :new_email,
    name = :new_name
WHERE id = :id;

выполнит обновление независимо от фактического изменения значений. В PostgreSQL это приводит к созданию новой версии строки в рамках MVCC, увеличению объёма WAL, дополнительным вызовам триггеров и генерации ненужных событий при использовании репликации или систем обработки изменений. Более точный вариант:

UPDATE users
SET
    email = :new_email,
    name = :new_name
WHERE id = :id
  AND (
      email IS DISTINCT FROM :new_email
      OR name IS DISTINCT FROM :new_name
  );

Такой подход позволяет выполнять обновление только при изменении данных. Он применяется в API, системах синхронизации, импортерах данных и интеграционных процессах. 🔥 IS DISTINCT FROM — оператор, который обеспечивает корректное сравнение значений с NULL и помогает избегать лишних операций записи в базе данных. ➡️ SQL Ready | #практика

Издательский дом «Новые отраслевые медиа» собрал для вас лучшие каналы из сферы искусственного интеллекта и интернет-технологий, которые помогают своим подписчикам быть в курсе всех важных профессиональных новостей. Здесь - всё про ключевых игроков отрасли, государственное регулирование, инсайды и кейсы от отраслевых лидеров. ✅Серверная - канал об индустрии дата-центров: технологиях, инфраструктуре, облачных решениях, энергоэффективности и применении ЦОД в ключевых отраслях экономики. ✅Робосфера - канал об индустрии робототехники: технологии и тренды. Промышленные и сервисные роботы, коботы, автоматизация, ИИ, машинное зрение, автономные системы. ✅AI для бизнеса - всё об AI-решениях для бизнеса: внедрение, автоматизация, корпоративный ИИ, агенты. ✅ТехноРитейл - канал о производстве и продаже бытовой техники и электроники в России: бренды, e-com, маркетинг, retail tech. Подписывайтесь, и эти каналы смогут изменить вашу жизнь к лучшему! Реклама. Харламов А.Е. ИНН 712803816807. erid: 2W5zFJPwAru

🧐 SQL Murder Mystery — изучаем SQL через детективное расследование! Этот репозиторий превращает изучение SQL в интерактивную детективную игру. Вместо обычных упражнений вам предстоит расследовать преступление, постепенно находя улики и анализируя данные с помощью SQL-запросов. Такой формат позволяет не просто запоминать синтаксис, а учиться работать с реальными данными. Оставляю ссылочку: GitHub 📱 ➡️ SQL Ready | #репозиторий

Почему EXISTS в SQL часто лучше использовать для проверки наличия данных, чем COUNT(*)! Одна из распространённых задач в SQL — определить, существует ли хотя бы одна запись, соответствующая заданному условию. Для этого иногда используют COUNT(*), хотя его основное назначение — вычисление количества строк, а не проверка факта существования данных. Например, есть таблица пользователей:

id | email
---+-----------------
1  | user@test.com
2  | admin@test.com
3  | test@test.com

Проверка наличия пользователя через COUNT(*):

SELECT
    COUNT(*)
FROM users
WHERE email = 'user@test.com';

Такой запрос вернёт количество найденных строк. Если требуется только узнать, существует ли запись, получение точного количества всех совпадений не является необходимым. Для проверки факта существования данных лучше подходит EXISTS:

SELECT EXISTS (
    SELECT 1
    FROM users
    WHERE email = 'user@test.com'
);

EXISTS возвращает логическое значение: TRUE, если найдена хотя бы одна подходящая строка, и FALSE, если совпадений нет. При выполнении такого запроса оптимизатор базы данных может использовать стратегию с ранним завершением проверки после нахождения первого совпадения, так как дальнейший поиск для этой операции не имеет смысла. Разница особенно заметна в больших таблицах и в часто выполняемых проверках внутри бизнес-логики: при создании пользователей, проверке связей между сущностями, наличии связанных данных и других условных операциях. Например, проверка наличия заказов пользователя через COUNT(*):

SELECT
    COUNT(*)
FROM orders
WHERE user_id = 100;

Этот запрос отвечает на вопрос: сколько заказов существует у пользователя. Если требуется только проверить наличие хотя бы одного заказа:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 100
);

В этом случае запрос точно отражает бизнес-логику: нужно проверить существование данных, а не выполнять подсчёт всех строк. COUNT(*) остаётся правильным выбором, когда необходимо получить фактическое количество записей:

SELECT
    COUNT(*) AS orders_count
FROM orders
WHERE user_id = 100;

Например, для формирования отчётов, статистики или отображения количества элементов. При наличии индекса по колонкам, используемым в условии WHERE, EXISTS может эффективно использовать возможности оптимизатора и быстро определить наличие подходящей записи. 🔥 Важно понимать разницу: COUNT(*) отвечает на вопрос: сколько строк существует? EXISTS отвечает на вопрос: существует ли хотя бы одна строка? Выбор правильного оператора делает SQL-запросы более выразительными и лучше соответствует реальной задаче приложения. ➡️ SQL Ready | #практика

На Stepik вышла программа «DevOps с нуля: от Linux до Kubernetes» Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes Вы последовательно пройдёте путь от работы в Linux и управления кодом через Git до контейнеризации приложений, настройки CI/CD-пайплайнов и развёртывания в Kubernetes. Что вы изучите:

• работу с Linux и командной строкой • Git и контроль версий в реальных проектах • создание Docker-образов и запуск контейнеров • автоматизацию сборки, тестирования и деплоя в GitLab CI/CD • развёртывание и управление приложениями в Kubernetes • сети, хранилища, конфигурации и секреты • диагностику инфраструктуры и автоматизацию рутинных задач ... и многое другое

Все знания закрепляются на практике с помощью заданий с автопроверкой. Материал подаётся последовательно и понятным языком: с примерами, схемами и демонстрациями. Во время обучения можно задавать вопросы по урокам и заданиям, получать обратную связь и помощь при возникновении сложностей. После прохождения программы вы получите сертификат, который можно добавить в резюме. Скидка 20% на 48 часов: по промокоду READY20 стоимость всей программы составит 10 392 ₽. Открыть программу на Stepik

📂 Напоминалка по работе с данными: Pandas — Polars — SQL! Например, groupby() в Pandas и Polars выполняет роль GROUP BY в SQL, merge() аналогичен JOIN, sort_values() заменяет ORDER BY, а unique() работает как SELECT DISTINCT. На картинке — основные операции для работы с таблицами: загрузка данных, просмотр строк, фильтрация, сортировка, группировка, объединение таблиц, переименование и удаление колонок в Pandas, Polars и SQL. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

🧐 SQLler — интерактивный тренажёр для изучения SQL! На сайте можно изучать SQL на практике, выполняя запросы прямо в браузере. Здесь собраны уроки по основным темам: подзапросы, агрегатные функции и другие конструкции, которые используются при работе с базами данных. Ресурс подойдёт новичкам, а также разработчикам и аналитикам, желающим закрепить знания с помощью практики. 📌 Оставляю ссылочку: sqller.com ➡️ SQL Ready | #ресурс

Вычисляемые значения на стороне PostgreSQL! Если значение полностью зависит от других колонок, не обязательно считать его перед каждым INSERT и UPDATE. PostgreSQL умеет делать это сам и всегда гарантирует корректный результат.

INSERT INTO orders(price, quantity)
VALUES (100, 3);

SELECT total
FROM orders
WHERE id = 1;

Поле total заполнится автоматически. Его нельзя случайно забыть обновить или вычислить по старой формуле.

UPDATE orders
SET quantity = 5
WHERE id = 1;

SELECT total
FROM orders
WHERE id = 1;

После изменения исходных данных значение пересчитается автоматически.

ALTER TABLE products
ADD COLUMN search_name text
GENERATED ALWAYS AS (lower(name)) STORED;

Это удобно для нормализованных значений, поисковых ключей, вычисляемых сумм и любых других детерминированных данных, которые должны всегда оставаться консистентными. 🔥 Если колонка полностью вычисляется из других колонок, пусть этим занимается PostgreSQL. Логику проще поддерживать, когда вычисление в одном месте. ➡️ SQL Ready | #совет

Настроил чат-бота за пару часов → заработал 9 000₽. Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу. А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени. Разница в зарплате: 200 тысяч. И нет — не надо ничего программировать. Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе. Без опыта. За 3-4 часа. 💡 Суть проста: Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги. В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно. Всё, что нужно для старта — запустить бота 👉 @other_digital_bot Там пошаговый план как стартануть и гайд по клиентам. До 27 июля вход бесплатный.

📂 Напоминалка по выбору NoSQL баз данных для проектов! Например, MongoDB подходит для работы с гибкими документными структурами, Redis — для высокопроизводительного кэширования и хранения данных в памяти, а Cassandra — для распределённых систем с огромными объёмами данных и высокой доступностью. На картинке — сравнение популярных NoSQL решений, их особенностей и основных сценариев использования: от поиска и аналитики до IoT, социальных сетей, e-commerce и real-time приложений. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

😍 CitForum Database — большая база материалов по SQL и СУБД! На сайте собрана крупная библиотека материалов по базам данных: SQL, проектирование БД, транзакции, индексы, оптимизация запросов и администрирование различных СУБД. Здесь можно найти статьи, учебные пособия, техническую документацию и обзоры по PostgreSQL, MySQL, Oracle, Microsoft SQL Server и другим системам управления базами данных. 📌 Оставляю ссылочку: citforum.ru ➡️ SQL Ready | #ресурс