Типы JOIN в SQL и когда их применять

- INNER JOIN - пересечение множеств (только совпавшие строки).
- LEFT JOIN - все слева + совпавшие справа (несовпавшие → NULL).
- RIGHT JOIN - симметричен LEFT, лучше переворачивать под LEFT.
- FULL OUTER JOIN - все слева и справа (где нет пары → NULL).
- CROSS JOIN — декартово произведение (каждая со всеми).
- SELF JOIN - таблица соединяется сама с собой.
- SEMI / ANTI JOIN - “есть/нет соответствия” (через EXISTS / NOT EXISTS).
- LATERAL / APPLY - зависимая подзапросная таблица на строку слева.


1️⃣ INNER JOIN - «строго есть пара»

«Покажи оплаченные заказы с данными клиента».

SELECT o.id, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'paid';

Используйте, когда отсутствие пары - повод исключить строку.

2️⃣ LEFT JOIN - «все слева, даже без пары»

«Список клиентов и количество их заказов (включая с нулём)».

SELECT c.id, c.name, COALESCE(COUNT(o.id), 0) AS orders_cnt
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;

По умолчанию для «обогащения» справочниками и опциональных связей.

3️⃣ RIGHT JOIN - почти не нужен

Заменяйте на LEFT, поменяв стороны:

-- было:
-- SELECT ... FROM A RIGHT JOIN B ON ...
-- стало:
SELECT ... 
FROM B
LEFT JOIN A ON ...

4️⃣ FULL OUTER JOIN - «объединить всё»

«Свод по всем клиентам и всем заказам, даже если без пары».

SELECT COALESCE(c.id, o.customer_id) AS customer_key, c.name, o.id AS order_id
FROM customers c
FULL JOIN orders o ON o.customer_id = c.id;

Редко нужен в отчётах/сверках. Поддержка зависит от СУБД.

5️⃣ CROSS JOIN - «все комбинации»

«Собрать сетку метрик по всем регионам и кварталам».

SELECT r.region, q.quarter
FROM regions r
CROSS JOIN quarters q;

Осторожно: взрыв строк.

6️⃣ SELF JOIN - «сравнить строки внутри таблицы»

«Найти менеджера и его подчинённого».

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON m.id = e.manager_id;

7️⃣ SEMI JOIN (EXISTS) - «фильтрация по факту наличия»

«Клиенты, у кого были заказы за 30 дней».

SELECT c.*
FROM customers c
WHERE EXISTS (
  SELECT 1 FROM orders o
  WHERE o.customer_id = c.id
    AND o.created_at >= CURRENT_DATE - INTERVAL '30 day'
);

Не размножает строки, часто быстрее, чем JOIN + DISTINCT.

8️⃣ ANTI JOIN (NOT EXISTS) - «кто без соответствий»

«Товары, которые ни разу не покупали в этом году».

SELECT p.*
FROM products p
WHERE NOT EXISTS (
  SELECT 1 FROM order_items oi
  JOIN orders o ON o.id = oi.order_id
  WHERE oi.product_id = p.id
    AND o.created_at >= date_trunc('year', CURRENT_DATE)
);

Избегайте NOT IN с NULL - может дать пустой результат.

9️⃣ LATERAL / APPLY - «топ-N на строку»

«Последний заказ на клиента» (PostgreSQL: LATERAL, SQL Server: APPLY).

SELECT c.id, c.name, o_last.id AS last_order_id
FROM customers c
LEFT JOIN LATERAL (
  SELECT o.id
  FROM orders o
  WHERE o.customer_id = c.id
  ORDER BY o.created_at DESC
  LIMIT 1
) o_last ON true;

💡Подводные камни

- LEFT JOIN + фильтр в WHERE ⇒ превращается в INNER.
Если нужно оставить «без пары», переносите условие в ON:

  -- ❌ неверно
  SELECT ... FROM c LEFT JOIN o ON o.customer_id = c.id
  WHERE o.status = 'paid';

  -- ✅ верно
  SELECT ... FROM c LEFT JOIN o
    ON o.customer_id = c.id AND o.status = 'paid';
  

- Дубликаты из «один-ко-многим». Перед JOIN делайте агрегацию в подзапросе/CTE.
- Индексы на ключах соединений (FK и соответствующие PK/UK) - must.
- Сопоставимость типов/колляций. Функции на ключе (LOWER(col)) ломают sargability - лучше нормализовать данные заранее.
- EXISTS чаще лучше, чем JOIN + DISTINCT для фильтрации.
- Проверяйте план. EXPLAIN (ANALYZE, BUFFERS) и сравнение альтернатив.

Сохрани, чтобы не забыть. А как вы чаще фильтруете - через JOIN+DISTINCT или EXISTS?


📲 Мы в MAX

#db #SQL

👉 @database_info

7 SQL-запросов, которые решают 90% всех задач на работе

Каждый день одно и то же. Открываешь клиент базы данных, чтобы что-то проверить, посчитать или найти. И снова пишешь почти тот же SELECT, что и вчера, с тем же WHERE и JOIN. Знакомо?

SQL в большинстве случаях не требует сложные 100-строчные запросы с вложенными подзапросами на три уровня глубины. Чаще всего нам нужны простые, отточенные и, главное, эффективные конструкции.

В этой статье я собрал 7 таких запросов-«рабочих лошадок». Это не какой-то там справочник, а готовая шпаргалка для реальных задач.

https://habr.com/ru/companies/timeweb/articles/943298/

📲 Мы в MAX

#db

👉 @database_info

🖥 Основы SQL за час - бесплатно и проще некуда

Содержание:
00:00 - подготавливаем базу
04:36 - выбираем данные SELECT
08:30 - указываем текущую базу данных
09:58 - чувствительность к регистру
12:14 - выбор определенных колонок
15:28 - фильтрация с помощью WHERE
20:59 - фильтрация с И и ИЛИ
26:38 - поиск строки по шаблону
29:18 - свой среди чужих
31:26 - NULL когда данные отсутствуют
34:27 - сортировка данных в SQL
38:37 - добавление записей с помощью SQL запроса
45:36 - обновление данных с помощью SQL
52:32 - удаляем данные из базы с помощью SQL

источник

📲 Мы в MAX

#db

👉 @database_info

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

📲 Мы в MAX

#db

👉 @database_info

Визуализация SQL-запроса

📲 Мы в MAX

#db

👉 @database_info

Шардирование базы данных на пальцах

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

Шардирование (шардинг) базы данных — это деление данных на разные фрагменты с целью повышения производительности и надежности. Иногда это понятие путают с репликацией и партицированием, но на самом деле это разные направления масштабирования, которые могут быть реализованы в пределах одной базы данных.

Существует два вида шардирования:

▪Вертикальное (по столбцам): каждый шард содержит часть столбцов массива и все связанные с ними строки данных.
▪Горизонтальное (по каким-либо критериям строки): каждый шард содержит одинаковые столбцы, но разные строки данных.

https://architecturenotes.co/database-sharding-explained/

📲 Мы в MAX

#db

👉 @database_info

Как лучше всего изучать язык SQL?

В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучить?

В состав языка SQL входят 5 компонентов:
- DDL: data definition language, such as CREATE, ALTER, DROP
- DQL: data query language, such as SELECT
- DML: data manipulation language, such as INSERT, UPDATE, DELETE
- DCL: data control language, such as GRANT, REVOKE
- TCL: transaction control language, such as COMMIT, ROLLBACK

Для бэкенд-инженера может потребоваться знание большинства из них. Аналитику данных может потребоваться хорошее понимание DQL. Выберите те темы, которые наиболее актуальны для вас.

📲 Мы в MAX

#db

👉 @database_info

Безумные и забавные факты о SQLite

⚫️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite.

⚫️Её поддерживают три человека. Они не допускают внешних контрибьюторов.
Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду.

https://habr.com/ru/companies/ruvds/articles/873816/

📲 Мы в MAX

#db

👉 @database_info