sql_ready | Unsorted

Telegram-канал sql_ready - SQL Ready | Базы Данных

7786

Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it

Subscribe to a channel

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

🖥 Как гарантировать одну активную запись?

Во многих системах есть правило: у пользователя, товара или сущности должна быть только одна активная запись. Если проверять это в коде, при конкурентных запросах правило легко нарушается.

Сегодня в гайде:

Почему логика обновить + вставить ломается;

Как зафиксировать правило на уровне базы;

Как условный уникальный индекс предотвращает дубликаты.


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

➡️ SQL Ready | #гайд

Читать полностью…

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

NULLIF в SQL: простой способ не словить деление на ноль!

Очень частая задача в SQL — нужно что-то на что-то поделить. Например, посчитать средний чек, конверсию или процент выполнения.

Есть таблица:

sales(id, revenue, orders_count)


Самый очевидный вариант:
SELECT
id,
revenue / orders_count AS avg_order_value
FROM sales;


На первый взгляд всё нормально. Но как только orders_count = 0, начинаются проблемы: в ряде СУБД такой запрос упадёт с ошибкой.

Обычно в таких местах используют NULLIF:
SELECT
id,
revenue / NULLIF(orders_count, 0) AS avg_order_value
FROM sales;


Что здесь происходит: NULLIF(orders_count, 0) вернёт: orders_count, если это не ноль; NULL, если это ноль.

Соответственно: если знаменатель не ноль — деление выполняется как обычно; если знаменатель ноль — получится NULL.

И это как раз правильное поведение. Потому что NULLIF не исправляет данные и не подменяет ноль каким-то удобным значением. Он просто говорит: в этой строке результат не определён.

Иногда после этого пишут так:
SELECT
id,
COALESCE(revenue / NULLIF(orders_count, 0), 0) AS avg_order_value
FROM sales;


Так делать можно, но только если 0 здесь действительно имеет смысл.

Потому что: NULL — значение не определено; 0 — значение определено и равно нулю. Это разные вещи. И подмена одного другим — уже не технический, а смысловой выбор.

Ещё пример:
SELECT
id,
success_count * 100.0 / NULLIF(total_count, 0) AS success_percent
FROM stats;


Почему именно 100.0, а не 100? Чтобы не получить целочисленное деление в тех СУБД, где дробная часть иначе отбросится.

То же самое можно записать и через CASE:
SELECT
id,
CASE
WHEN orders_count = 0 THEN NULL
ELSE revenue / orders_count
END AS avg_order_value
FROM sales;


Это тоже нормальный вариант. Но когда задача именно в защите от деления на ноль, NULLIF обычно короче и читается быстрее.

Ещё момент, который часто путают:
SELECT
SUM(revenue) / NULLIF(SUM(orders_count), 0) AS avg_order_value
FROM sales;


а также:
SELECT
AVG(revenue / NULLIF(orders_count, 0)) AS avg_order_value
FROM sales;


Это разные расчёты. В первом случае — общая выручка делится на общее число заказов. Во втором — считается среднее от построчных значений, причём AVG пропускает NULL.

🔥 Итог простой: NULLIF(x, 0) — приём, который в реальных запросах спасает. Особенно когда хочется не просто чтобы не упало, а чтобы результат оставался корректным по смыслу.

➡️ SQL Ready | #практика

Читать полностью…

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

Индекс с INCLUDE: уменьшаем чтение таблицы!

Даже если у вас есть индекс, PostgreSQL часто всё равно идёт в таблицу за остальными колонками — это лишний I/O, особенно на больших данных:

CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at DESC)
INCLUDE (total, status);


INCLUDE добавляет дополнительные колонки в индекс (payload), но они не участвуют в поиске и сортировке, часто это выгоднее, чем делать их частью ключа:
SELECT user_id, created_at, total, status
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 1;


Теперь все нужные поля есть в индексе, и PostgreSQL может выполнить запрос через Index Only Scan, уменьшая или исключая обращения к таблице (heap):
EXPLAIN ANALYZE SELECT ...


В плане вы увидите Index Only Scan (иногда с Heap Fetches) вместо Index Scan — это значит, что обращения к таблице сокращены или отсутствуют.

🔥 Один из практических бустов в read-heavy сценариях и частых API-запросах.

➡️ SQL Ready | #совет

Читать полностью…

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

DISTINCT — убираем дубликаты прямо в SQL!

Иногда таблица содержит повторы, а нам нужны только уникальные строки. DISTINCT позволяет легко отфильтровать дубликаты на уровне запроса — без дополнительной логики.

Выберем все уникальные города из таблицы клиентов:

SELECT DISTINCT city FROM customers;


Теперь получим только уникальные пары "страна + город":
SELECT DISTINCT country, city FROM customers;


А вот как посчитать количество разных городов:
SELECT COUNT(DISTINCT city) FROM customers;


В PostgreSQL можно выбирать первую уникальную строку по группе значений:
SELECT DISTINCT ON (user_id) *
FROM logins
ORDER BY user_id, login_time DESC;


🔥 DISTINCT полезен для отчётов, списков, фильтрации и аналитики. Но помните: он влияет на производительность — особенно при работе с большими таблицами.

➡️ SQL Ready | #практика

Читать полностью…

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

Курсы по кибербез, белый хакинг, социальная инженерия, безопасность

ИБ Книга
Более 1660 русскоязычных книг по ИБ и Социальной Инженерии можно найти на канале.

no system is safe // cybersec — один из древнейших ресурсов по информационной безопасности в рунете. Книги, курсы, полезные тулсы, уроки по Linux, новости клирнета и даркнета.

Python и 1000 программ уроки по Python. Python мы будем использовать для создания OSINT софта.

Весь материал на каналах в общем доступе. Ничего лишнего

Читать полностью…

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

🖥 Oracle SQL: основные строковые функции!

Основные функции обработки строк в Oracle SQL: извлечение подстрок, определение позиции подстроки, вычисление длины строки, преобразование регистра, удаление лишних символов по краям, замена фрагментов текста и дополнение строки до заданной длины.

➡️ SQL Ready | #шпора

Читать полностью…

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

PostgreSQL: CONCAT_WS, если нужно нормально собрать строку из колонок с NULL!

Частая мелочь в SQL — собрать одну строку из нескольких полей. Например, имя пользователя из first_name, middle_initial, last_name.

Таблица условно такая:

users(id, first_name, middle_initial, last_name)


Первое, что обычно пишут:
SELECT first_name || ' ' || middle_initial || ' ' || last_name
FROM users;


И тут важный момент: если хотя бы одно значение NULL, всё выражение тоже уйдёт в NULL.

То есть если middle_initial = NULL, то результат будет не Emily Johnson, а просто NULL.

В таких случаях удобнее использовать CONCAT_WS:
SELECT CONCAT_WS(' ', first_name, middle_initial, last_name)
FROM users;


CONCAT_WS склеивает значения через разделитель и просто пропускает NULL.

Если middle_initial = 'A': Emily A Johnson. Если middle_initial = NULL: Emily Johnson.

Плюс не нужно отдельно думать про лишние пробелы — разделитель вставится только там, где есть значение.

Важно: CONCAT_WS пропускает именно NULL. Пустая строка не игнорируется.

То же самое можно собрать и через COALESCE, например так:
SELECT
COALESCE(first_name || ' ', '') ||
COALESCE(middle_initial || ' ', '') ||
COALESCE(last_name, '')
FROM users;


Но это уже выглядит тяжелее, особенно когда полей больше двух-трёх.

🔥 Так что для таких кейсов CONCAT_WS обычно самый нормальный вариант: и короче, и читается лучше.

➡️ SQL Ready | #практика

Читать полностью…

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

💡 SQL by Example — SQL-шпаргалка с примерами запросов!

Здесь разобраны реальные примеры запросов: выборки, фильтрация, JOIN-ы, подзапросы, агрегации и другие ключевые конструкции, которые чаще всего используются при работе с базами данных. Формат максимально простой: пример, объяснение, результат, поэтому можно быстро понять, как работает конкретный запрос и сразу применить его в своих задачах.

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


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

Читать полностью…

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

Ждал меня? Признавайся…

А я уже собрал все ИИ новости и инструменты в одном telegram-канале. Как ими пользоваться, как адаптировать под разные профессии, все тут. Даже твоя бабушка поймет 😎

Подпишись. Пользуйся.

Читать полностью…

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

📂 Напоминалка по типам серверов!

Например, DNS Server помогает найти нужный IP по доменному имени, а Proxy Server может скрыть тебя от внешней сети.

На картинке — 6 типов серверов, которые стоит понимать каждому разработчику.

Сохрани, чтобы не забыть!

SQL Ready | #ресурс

Читать полностью…

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

Передавайте списки значений через массивы вместо длинных IN!

Когда из приложения нужно передать список id в SQL, многие пишут IN (... , ... , ...), что увеличивает текст SQL и усложняет работу с prepared statements:

WHERE id IN (1,2,3,4,5,6,7)


PostgreSQL умеет принимать массив и сравнивать его через ANY — это короче и позволяет избежать генерации динамического SQL:
WHERE id = ANY($1)


Приложение просто передаёт массив параметром, а текст запроса остаётся неизменным независимо от длины списка:
SELECT *
FROM users
WHERE email = ANY($1);


На практике полезно явно указывать тип массива ($1::bigint[]), а также помнить, что NULL внутри массива влияет на результат сравнения.

🔥 Этот паттерн особенно удобен для batch-запросов, API-фильтров и массовых выборок, где количество значений может сильно меняться.

➡️ SQL Ready | #совет

Читать полностью…

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

SEMI JOIN через EXISTS — как корректно проверять наличие связанных строк!

Частая задача в SQL — выбрать строки из одной таблицы, если в другой таблице существует хотя бы одна связанная запись.

Таблицы:

customers(id, name)
orders(id, customer_id, created_at)


Нужно получить клиентов, у которых есть хотя бы один заказ.

Попытка через JOIN:
SELECT
c.id,
c.name
FROM customers c
JOIN orders o
ON o.customer_id = c.id;


Запрос вернёт клиентов, но если у клиента несколько заказов, он появится в результате несколько раз.

Чтобы убрать дубликаты, часто добавляют DISTINCT:
SELECT DISTINCT
c.id,
c.name
FROM customers c
JOIN orders o
ON o.customer_id = c.id;


Результат будет корректным, однако такой запрос выражает задачу менее точно: JOIN формирует строки для каждого совпадения, а DISTINCT затем устраняет повторяющиеся значения.

В подобных задачах фактически требуется semi join — вернуть строку из customers, если существует хотя бы одна связанная строка в orders.

В большинстве СУБД это обычно выражают через EXISTS:
SELECT
c.id,
c.name
FROM customers c
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.customer_id = c.id
);


Подзапрос проверяет наличие хотя бы одной строки в orders, связанной с текущим клиентом.

Оптимизатор часто может завершить проверку сразу после нахождения первого совпадения, поэтому EXISTS является естественным инструментом для проверки существования строк.

Практический пример — клиенты, которые делали заказы после определённой даты:
SELECT
c.id,
c.name
FROM customers c
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.customer_id = c.id
AND o.created_at >= '2025-01-01'
);


EXISTS не возвращает данные из подзапроса — он только проверяет факт существования строки.

Поэтому внутри обычно пишут:
SELECT 1


или:
SELECT *


В контексте EXISTS список выбираемых выражений не влияет на результат.

🔥 EXISTS — стандартный и выразительный способ реализовать semi join. Он точно отражает намерение запроса и часто позволяет оптимизатору построить более эффективный план выполнения.

➡️ SQL Ready | #практика

Читать полностью…

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

Атомарное перемещение данных между таблицами!

Иногда нужно архивировать старые данные: удалить их из основной таблицы и одновременно сохранить в архиве. Многие делают это двумя запросами (INSERT => DELETE):

DELETE FROM orders
RETURNING *


RETURNING позволяет сразу вернуть удалённые строки как результирующий набор, не выполняя повторный SELECT.
WITH moved AS (...)


CTE превращает результат удаления во временный набор данных, который можно использовать в следующей операции:
INSERT INTO orders_archive
SELECT * FROM moved;


В итоге строки удаляются и архивируются одним атомарным запросом, без повторного чтения таблицы.

🔥 Полезный паттерн для архивирования, миграций, дедупликации и batch-операций над большими таблицами.

➡️ SQL Ready | #совет

Читать полностью…

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

🖥 Анализ средней длительности сессий пользователей по устройствам!

В этой задаче напишем SQL-запрос, который поможет вычислить среднее время сессии для пользователей на разных устройствах за последние 30 дней.

Что делаем:

Фильтруем сессии по времени и устройствам.

Считаем длительность каждой сессии.

Группируем и находим среднее время по типам устройств.


Такой анализ помогает понять, в каких моментах сфокусироваться на улучшении UX и маркетинговых кампаниях.

➡️ SQL Ready | #задача

Читать полностью…

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

Агрегирование по группам с оконными функциями!

Когда нужно посчитать агрегаты по группе и при этом сохранить исходные строки, многие делают подзапрос с GROUP BY и потом джойнят его обратно:

SUM(o.total) OVER (PARTITION BY o.user_id)


Оконная функция считает агрегат по группе, но не схлопывает строки, поэтому не нужен ни GROUP BY, ни повторное соединение:
AVG(o.total) OVER (PARTITION BY o.user_id)


Можно получить любые метрики по той же группе в одном проходе по данным:
COUNT(*) OVER (PARTITION BY o.user_id)


Особенно полезно для аналитики, отчётов, флагов “у пользователя больше N заказов” и подобных задач без лишних подзапросов.

🔥 Один из самых эффективных способов упростить сложные запросы.

➡️ SQL Ready | #совет

Читать полностью…

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

❤️ Use The Index, Luke — полезный ресурсов по оптимизации SQL!

Это гайд по производительности SQL, где подробно объясняется, как работают индексы и как с их помощью ускорять запросы. Материал построен с нуля и ориентирован именно на разработчиков, без лишней теории и перегруженной терминологии. Всё объясняется через практику и примеры.

📌 Оставляю ссылочку: use-the-index-luke.com

➡️ SQL Ready | #ресурс

Читать полностью…

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

👍 SQL Cheat Sheet — удобнейшая и информативная шпаргалка!

Этот компактный и понятный справочник по SQL, где собраны основные команды, конструкции и паттерны, которые используются в работе. Всё оформлено с примерами, поэтому можно быстро вспомнить синтаксис или найти нужную команду без долгого поиска. Отлично подходит как справочник в работе, для повторения базы и подготовки к собеседованиям.

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


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

Читать полностью…

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

📂 Напоминалка по типам баз данных!

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

На картинке — 4 типа баз данных, их особенности, преимущества и где их лучше применять.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс

Читать полностью…

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

Совет на 2026 год — переходите в ML.

Пока обычные разрабы конкурируют с ИИ-копилотами, ML-инженеры эти самые нейронки создают.

В эпоху нейростей это самые востребованые люди в мире программирования. Зарплаты мидлов начинаются от 250 000 ₽, а у сеньоров в BigTech доходят до 700 000 ₽.

А чтобы освоить его всего за 4 месяца без лишней суеты — изучите канал Артема Алехина.

Его бэкграунд: Руководитель команды в Сбере, валютная удаленка. К 22 годам вышел на доход 1 000 000+ ₽ в месяц.

На канале вы найдёте:

— Всё про самые востребованные стеки(Python, ИИ-агенты, NLP) и почему математика — это не страшно, если учить только нужное.

— Как оформить резюме, чтобы оно пролетало через любые LLM-фильтры и ATS-системы прямо к тимлидам.

— Скрипты переговоров, которые помогли его ученикам прыгнуть с 0 до 360к всего за 8 месяцев.

Во времена острой нехватки ML-разработчиков, это лучшее время, чтобы перекатиться. Переходи и изучай: /channel/+zFlLy16mPM40Zjc6

Читать полностью…

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

🖥 Быстрый ориентир по SQL-командам!

Когда нужно создать таблицу или изменить её структуру — берём DDL. Хотим изменить данные внутри — используем DML. А если нужно просто вытянуть информацию — поможет DQL с её незаменимым select.

Полезно держать под рукой, чтобы не забыть!

➡️ SQL Ready | #ресурс

Читать полностью…

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

❤️ Полезную статью нашёл на Хабре: «Почему SUM() OVER (ORDER BY ...) иногда считает “неправильно”: разбираем оконные фреймы в SQL»!

В этой статье:
• Объясняется, как на самом деле работают оконные функции в SQL и почему результаты иногда отличаются от ожидаемых;
• Разбираются ключевые типы оконных фреймов — ROWS, RANGE и GROUPS, а также их влияние на вычисления;
• Показано, как правильно задавать границы окна (UNBOUNDED PRECEDING, CURRENT ROW, FOLLOWING) для накопительных итогов, скользящих средних и аналитических запросов.


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


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

Читать полностью…

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

На Stepik добавили курс «Linux с нуля»

Этот курс закрывает всю обязательную Linux-базу для работы в IT. Подойдёт для:

- разработчиков
- девопсов и админов
- специалистов по данным и ML
- специалистов поддержки и сопровождения
- тестировщиков и безопасников


Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой)

Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами

После прохождения вы получите сертификат, который можно добавить в резюме.

В ближайшие 48ч курс доступен со скидкой 30% по промокоду «READY30»: открыть курс на Stepik

Читать полностью…

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

Получение top-N строк с учётом равных значений!

Иногда нужно получить не просто N строк, а все записи, которые имеют такое же значение сортировки, как и последняя строка в выборке.

Это полезно для топ-продаж, логов и аналитики.

FETCH FIRST 5 ROWS ONLY


Обычный LIMIT / FETCH возвращает ровно N строк и может «обрезать» записи с таким же значением сортировки.

WITH TIES возвращает все строки, у которых значение ORDER BY совпадает с последней строкой результата:
FETCH FIRST 5 ROWS WITH TIES


Это удобно для построения top-N выборок, где несколько строк могут делить одно и то же место:
ORDER BY score DESC
FETCH FIRST 10 ROWS WITH TIES


WITH TIES не заменяет RANK() / DENSE_RANK(), если нужен полноценный рейтинг с номером места. Также проверьте синтаксис в вашей СУБД (например, в SQL Server используется TOP ... WITH TIES).

🔥 Такой приём позволяет строить top-выборки без дополнительных подзапросов и оконных функций.

➡️ SQL Ready | #совет

Читать полностью…

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

📂 Напоминалка по архитектуре PostgreSQL и MySQL!

PostgreSQL работает через процессы и shared memory, а системой управляет Postmaster и фоновые процессы. MySQL использует слоистую архитектуру: подключение, обработка SQL и storage engine (например InnoDB).

На картинке — основные компоненты и различия архитектуры двух популярных СУБД.

Сохрани, чтобы не забыть!

➡️ SQL Ready | #ресурс

Читать полностью…

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

VACUUM — чистим таблицу и ускоряем работу базы!

В большинстве СУБД удалённые или обновлённые строки не удаляются мгновенно, а остаются как «мертвые» записи. Со временем это замедляет запросы и увеличивает размер таблиц — нужна очистка.

Сначала удаляем устаревшие записи из таблицы:

DELETE FROM sessions WHERE expired = true;


Однако физически строки всё ещё занимают место.

Чтобы освободить пространство и обновить статистику, запускаем:
VACUUM ANALYZE sessions;


Для диагностики можно получить подробный отчёт о процессе очистки:
VACUUM VERBOSE sessions;


🔥 Регулярный VACUUM поддерживает производительность и точность планов запросов.

➡️ SQL Ready | #практика

Читать полностью…

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

🐱 Крутейшая статья вышла на Хабре: «Научил ИИ-агента помнить важное и забывать лишнее в SQLite»!

В этой статье:
• Разбирается, почему классический RAG плохо подходит для долгоживущих AI-агентов;
• Показана архитектура когнитивной памяти на SQLite: граф узлов и рёбер, сущности, гибридный поиск и механизм разрешения конфликтов знаний;
• Объясняется, как реализовать память агента с механизмом забывания и консолидацией фактов.


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


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

Читать полностью…

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

❤️ RusauSQL — подробный учебник по SQL для тестировщиков и разработчиков!

Это большой гайд по SQL, где последовательно объясняется, как работать с базами данных и писать запросы. На сайте разбираются фундаментальные вещи: что такое SQL, как устроены таблицы и базы данных, как выполнять запросы, проверять данные и взаимодействовать с сервером через язык запросов. Отличный ресурс, если хочешь разобраться в SQL с практической стороны и понять работу баз данных.

📌 Оставляю ссылочку: rusau.net

➡️ SQL Ready | #сайт

Читать полностью…

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

📂 Напоминалка по SQL JOIN!

Например, LEFT JOIN позволяет получить все строки из левой таблицы, даже если соответствующих записей в правой таблице нет, а FULL OUTER JOIN возвращает все строки из обеих таблиц, заполняя отсутствующие значения NULL.

На изображении показаны 4 основных типа SQL JOIN, которые чаще всего используются при объединении данных из нескольких таблиц.

📌 Сохрани, чтобы не потерять!

➡️ SQL Ready | #ресурс

Читать полностью…

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

💡 Rows — умные таблицы с встроенным ИИ!

Сервис для работы с данными в формате таблиц (аналог Excel / Google Sheets) с интегрированными AI-инструментами. Позволяет анализировать данные, создавать формулы по описанию и подтягивать информацию из интернета и API. Подходит для аналитики, автоматизации и обработки больших массивов данных.

📌 Оставляю ссылочку: rows.com

➡️ SQL Ready | #ресурс

Читать полностью…

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

☕️ Полезную статью нашёл на Хабре: «Инженерная история: добавляем 3-ю СУБД в карточный процессинг»!

В этой статье:
• Разобрано, зачем в высоконагруженной системе может понадобиться сразу несколько СУБД и как между ними строится абстрактный слой доступа к данным;
• Показан опыт интеграции распределённой базы данных YDB в существующую архитектуру;
• Разбираются технические нюансы: батч-операции, строгая типизация запросов, особенности драйверов и результаты нагрузочного тестирования.


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


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

Читать полностью…
Subscribe to a channel