☕️ Годную статью нашёл на Хабре: «Как работает распределённый SQL в YDB: от запроса до выполнения»!

В этой статье:
• Показано, как в YDB обрабатывается SQL-запрос — от парсинга до распределённого исполнения по узлам;
• Разбирается, как устроены планировщик, оптимизатор и механизмы шардинга при работе с большими данными;
• Объясняется, как достигаются консистентность, отказоустойчивость и масштабируемость в распределённой базе.

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

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

😎 SQLServerCentral — крупнейшее сообщество и база знаний по Microsoft SQL Server!

Здесь публикуются ежедневные статьи, обучающие серии Stairway, подборки скриптов, обзоры книг, а также активные форумы и блоги для администраторов БД и разработчиков.

📌 Оставляю ссылочку: sqlservercentral

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

❤️ Нашел вам html5css — простой и наглядный справочник по SQL на русском!

Если хочется быстро разобраться в командах — этот сайт отлично подойдёт. Конструкции объяснены на примерах, с чётким и кратким синтаксисом. Удобно использовать как справочник или экспресс‑повторение.

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

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

📂 Напоминалка по реляционной модели и SQL!

Например, Primary Key гарантирует уникальность записей, Foreign Key — обеспечивает ссылочную целостность, а JOIN’ы позволяют собирать распределённые данные в единую выборку.

На картинке — основные концепции, которые используются при проектировании и работе с БД.

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

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

Проверяем дубликаты и считаем уникальные значения!

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

Создадим таблицу пользователей:

CREATE TABLE users (
    user_id INT,
    email VARCHAR(100)
);

INSERT INTO users VALUES
(1, 'alice@mail.com'),
(2, 'bob@mail.com'),
(3, 'alice@mail.com'),
(4, 'carol@mail.com'),
(5, 'bob@mail.com');

Запрос для выявления дубликатов и подсчёта уникальных email:

SELECT email, COUNT(*) AS cnt,
       CASE WHEN COUNT(*)>1 THEN 'Duplicate' ELSE 'Unique' END AS status
FROM users
GROUP BY email;

Функция COUNT() + GROUP BY группирует одинаковые значения, а CASE сразу классифицирует их как дубликаты или уникальные.

Результат:

email           | cnt | status
-----------------------------
alice@mail.com  | 2   | Duplicate
bob@mail.com    | 2   | Duplicate
carol@mail.com  | 1   | Unique

🔥 Это простой способ контролировать качество данных, выявлять ошибки и готовить отчёты для команды.

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

Использование data-modifying CTE для цепочек операций в одном запросе!

Обычно изменения и чтение делают разными запросами, что создаёт лишние round-trip и риск рассинхронизации данных между операциями:

UPDATE orders
SET status = 'processing'
WHERE id = 123
RETURNING *;

RETURNING уже даёт доступ к изменённым строкам, но data-modifying CTE позволяет пойти дальше и использовать их в следующих шагах:

WITH updated AS (...)

CTE фиксирует результат изменения и гарантирует, что последующие операции работают с тем же набором строк в рамках одного statement:

INSERT INTO audit_log (order_id, new_status)
SELECT id, status
FROM updated;

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

🔥 data-modifying CTE — это способ строить сложные, но безопасные цепочки операций внутри одного SQL-запроса.

➡️ SQL Ready | #совет

☕️ Полезную статью нашёл на Хабре: «Ваш RAG не умеет думать. А мой умеет»!

В этой статье:
• Разбирается, почему классические RAG-системы на базе векторных БД часто ограничиваются поверхностным поиском;
• Показан подход HippoRAG 2, где память и связи между фактами организованы ближе к графовой модели;
• Объясняется, как эволюционирует работа с данными;
• Рассматривается, как это влияет на SQL/NoSQL слой, архитектуру хранения и построение более осмысленных запросов к данным.

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

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

Дубликаты после JOIN — откуда берутся и как контролировать!

Одна из частых проблем — внезапное размножение строк после JOIN. Это базовое поведение, если не учтена кардинальность связей.

Таблицы:

orders(id, customer_id, amount)
payments(id, order_id, status)

Задача: получить заказы с информацией об оплате.

SELECT 
    o.id,
    o.amount,
    p.status
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

Если у одного заказа несколько платежей — в результат попадёт несколько строк. Фактически вы получаете по одной строке на каждое совпадение orders — payments. То есть один заказ повторится столько раз, сколько у него записей в payments.

Для связи 1:N это абсолютно ожидаемо. Где начинаются проблемы — агрегация:

SELECT 
    COUNT(*) AS total_orders
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

Здесь COUNT(*) считает строки уже после JOIN, а не заказы. Если у заказа 3 платежа — он попадёт в счёт 3 раза. Это одна из самых частых причин кривых метрик.

Корректный вариант:

SELECT 
    COUNT(DISTINCT o.id) AS total_orders
FROM orders o
LEFT JOIN payments p  
    ON p.order_id = o.id;

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

И отдельный момент, если вам нужно просто количество заказов без условий по payments, JOIN здесь вообще лишний. Лучше контролировать кардинальность до JOIN

Если задача — проверить наличие успешной оплаты, проще и дешевле использовать EXISTS:

SELECT 
    o.id,
    o.amount
FROM orders o
WHERE EXISTS (
    SELECT 1
    FROM payments p
    WHERE p.order_id = o.id
      AND p.status = 'success'
);

EXISTS работает как semi-join: он проверяет факт наличия строки, но не тянет её в результат. За счёт этого одна строка заказа остаётся одной строкой.

Если JOIN всё-таки нужен — агрегируем заранее:

SELECT 
    o.id,
    o.amount,
    COALESCE(p.has_success, 0) AS has_success
FROM orders o
LEFT JOIN (
    SELECT
        order_id,
        MAX(CASE WHEN status = 'success' THEN 1 ELSE 0 END) AS has_success
    FROM payments
    GROUP BY order_id
) p ON p.order_id = o.id;

Здесь мы сначала приводим payments к одной строке на order_id, и только потом делаем JOIN. После этого результат становится понятным: одна строка на заказ, без раздувания.

Типичная ошибка:

GROUP BY o.id, o.amount, p.status

Это не решит проблему. Такой GROUP BY просто фиксирует текущую детализацию. Если у заказа было несколько статусов — строки никуда не денутся.

🔥 JOIN не создаёт дубликаты сам по себе. Он возвращает строки в соответствии с числом совпадений по условию ON. Если после JOIN строк стало больше — значит реальная связь между таблицами не 1:1, а 1:N или даже N:M.

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

😎 SQL Server Kit — практическая база инструментов и материалов!

Репозиторий представляет собой обширную коллекцию скриптов, статей, рекомендаций и утилит для администрирования и разработки на SQL. Внутри собраны решения для диагностики производительности, оптимизации запросов, мониторинга, резервного копирования, работы с индексами и анализа состояния базы данных. Также представлены ссылки на проверенные источники и лучшие практики работы с СУБД.

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

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

😍 SQL PostgreSQL Course — информативный курс по SQL с практикой!

Это структурированное обучение по PostgreSQL: от базовых запросов до JOIN’ов, подзапросов и проектирования базы данных. Материал выстроен последовательно, поэтому легко идти шаг за шагом и не теряться в теме. Здесь есть практика с заданиями и ответами, за счёт чего обучение закрепляется.

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

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