Навигация по каналу:

🧠 #SQLQuiz : серия мини-задач для проверки знаний с решениями
❌ #SQLAntiPattern : разбор распространенных ошибок начинающих и как их избегать
🎯 #SQLСобеседование : Подготовка к SQL-собеседованию: типичные вопросы и как на них отвечать

🎯 #SQLСобеседование: Типы ключей и связи между таблицами

На собеседовании обязательно спросят про ключи и связи:

✅ Первичный ключ (Primary Key):

Уникально идентифицирует каждую строку в таблице
Не может содержать NULL
Обычно это поле i

🎯 #SQLСобеседование: Агрегатные функции и GROUP BY

На собеседовании часто спрашивают об агрегации данных:

✅ GROUP BY:
Группирует строки с одинаковыми значениями в указанных столбцах
Используется с агрегатными функциями
Пример: количество заказов по городам, сумма продаж по месяцам

✅ Агрегатные функции:
COUNT(): количество строк
SUM(): сумма значений
AVG(): среднее значение
MIN()/MAX(): минимальное/максимальное значение

✅ Важные нюансы:
COUNT(*) считает все строки, COUNT(column) - только не-NULL значения
GROUP BY должен включать все неагрегированные столбцы из SELECT
HAVING фильтрует результаты после группировки (WHERE фильтрует до)

Пример сложного запроса:

SELECT 
  category,
  COUNT(*) AS products_count,
  AVG(price) AS avg_price,
  MIN(price) AS min_price,
  MAX(price) AS max_price
FROM products
WHERE price > 0
GROUP BY category
HAVING COUNT(*) > 5
ORDER BY avg_price DESC;

🎯 #SQLСобеседование: Вопросы про JOIN

Один из самых частых вопросов: "Объясните разницу между типами JOIN"

✅ INNER JOIN:
Возвращает только строки, где есть совпадения в обеих таблицах
Пример: список заказов с именами клиентов (только для существующих клиентов)

✅ LEFT JOIN:
Все строки из левой таблицы + соответствующие строки из правой
Если нет совпадения, поля правой таблицы будут NULL
Пример: список всех клиентов и их заказы (включая клиентов без заказов)

✅ RIGHT JOIN:
То же самое, что LEFT JOIN, но наоборот
Редко используется (обычно меняют порядок таблиц и используют LEFT JOIN)

✅ FULL JOIN:
Комбинация LEFT и RIGHT JOIN
Все строки из обеих таблиц

🌟 Бонусный совет: нарисуйте диаграмму Венна для объяснения JOIN на интервью!

#JOINs #SQLInterview

🎯 #SQLAntiPattern: LIKE в начале строки

Частая ошибка при поиске по тексту:

-- Очень медленный запрос!
SELECT * FROM products 
WHERE name LIKE '%apple%';

Проблема: индексы не могут эффективно использоваться с LIKE, когда маска начинается с '%'!

✅ Решения:

1) Используйте полнотекстовый поиск:

-- PostgreSQL
SELECT * FROM products 
WHERE to_tsvector('english', name) @@ to_tsquery('apple');

-- MySQL
SELECT * FROM products 
WHERE MATCH(name) AGAINST('apple' IN NATURAL LANGUAGE MODE);

2) Создайте отдельную колонку для поиска:

-- При вставке:
UPDATE products SET name_lower = LOWER(name);

-- При поиске:
SELECT * FROM products 
WHERE name_lower LIKE '%apple%';

💡 Полнотекстовый поиск может быть в сотни раз быстрее LIKE '%...%'!

#SQLOptimization #ПроизводительностьSQL

🎯 #SQLAntiPattern: Отсутствие индексов

Запросы без индексов могут работать в ТЫСЯЧИ раз медленнее!

Проблемный запрос:

SELECT * FROM orders 
WHERE customer_email = 'user@example.com';

Если у нас миллионы заказов и нет индекса по customer_email, СУБД будет проверять КАЖДУЮ строку! 🐢

✅ Правильное решение:

CREATE INDEX idx_orders_customer_email ON orders(customer_email);

Как определить, нужен ли индекс?
- Используйте EXPLAIN для анализа запроса
- Индексируйте поля в WHERE, JOIN, GROUP BY, ORDER BY
- Учитывайте кардинальность (число уникальных значений)

💡 Помните: индексы ускоряют SELECT, но замедляют INSERT/UPDATE/DELETE.

#Индексы #SQLOptimization

🎯 #SQLAntiPattern: Игнорирование транзакций

Новички часто не используют транзакции для связанных операций:

-- Опасный подход:
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2; 

Что случится, если первый запрос выполнится, а второй упадет с ошибкой? Деньги "исчезнут"! 💸

✅ Правильный подход с транзакциями:

BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

При ошибке произойдет ROLLBACK, и состояние БД останется согласованным.

💡 Используйте транзакции всегда, когда изменения в разных таблицах должны происходить как единое целое!

#Транзакции #ЦелостностьДанных

🧠 #SQLQuiz: Сложная задача на подзапросы

Даны таблицы:

employees(id, name, department_id, salary)
departments(id, name)

Найдите для каждого отдела:
1) Сотрудника с максимальной зарплатой
2) Разницу между максимальной и средней зарплатой
3) Сотрудников, чья зарплата выше средней по их отделу

Вызов принят? 🤔

#SQL #SubQueries #ChallengeAccepted

🧠 #SQLQuiz: Задача на оконные функции

Дана таблица sales(id, date, amount, salesperson_id).

Напишите запрос, который для каждой продажи покажет:
1) сумму продажи
2) скользящую сумму за последние 3 продажи для каждого продавца
3) процент от общей суммы продаж продавца

Попробуйте решить! 💪

💡 Оконные функции позволяют проводить расчеты по группам данных без необходимости использования GROUP BY, сохраняя доступ к отдельным строкам!

#WindowFunctions #SQL #DataAnalysis

❌ #SQLAntiPattern: Бесконечные вложенные подзапросы

Многие новички пишут код с множеством уровней вложенности:

-- Сложный для понимания запрос
SELECT *
FROM (
  SELECT * 
  FROM (
    SELECT * 
    FROM products 
    WHERE category_id IN (
      SELECT id 
      FROM categories 
      WHERE active = true
    )
  ) AS active_products
  WHERE price > 100
) AS expensive_products
WHERE stock_quantity > 0;

✅ Лучшее решение - использовать CTE (Common Table Expressions)

WITH active_categories AS (
  SELECT id 
  FROM categories 
  WHERE active = true
),
active_products AS (
  SELECT * 
  FROM products 
  WHERE category_id IN (SELECT id FROM active_categories)
),
expensive_products AS (
  SELECT * 
  FROM active_products 
  WHERE price > 100
)
SELECT * 
FROM expensive_products
WHERE stock_quantity > 0;

💡 CTE делают код намного читабельнее и легче для сопровождения!

#CleanCode #SQLRefactoring

❌ #SQLAntiPattern: Неправильные типы данных

Выбор неподходящих типов данных - распространенная ошибка:

CREATE TABLE orders (
  id INT,
  customer_id INT,
  -- ❌ Плохо: хранить даты в виде строк
  order_date VARCHAR(10),
  -- ❌ Плохо: ограничение точности для денежных значений
  total_amount FLOAT,
  -- ❌ Плохо: хранить булевы значения как строки
  is_paid VARCHAR(5)
);

✅ Правильные типы данных:

CREATE TABLE orders (
  id INT,
  customer_id INT,
  -- ✅ Специальный тип для дат
  order_date DATE,
  -- ✅ Фиксированная точность для денег
  total_amount DECIMAL(10,2),
  -- ✅ Булевы значения
  is_paid BOOLEAN
);

💡 Правильные типы данных обеспечивают:
1) Целостность данных
2) Эффективное хранение
3) Корректные вычисления
4) Более быстрые запросы

#DatabaseDesign #DataTypes

❌ #SQLAntiPattern: Избыточные JOIN-ы

Избыточные соединения замедляют запросы и усложняют код:

-- Проблемный запрос с лишними JOIN
SELECT c.name, o.order_date, p.name AS product
FROM customers c
JOIN orders o ON c.id = o.customer_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
JOIN categories cat ON p.category_id = cat.id
JOIN suppliers s ON p.supplier_id = s.id
-- Категория и поставщик не используются в запросе!
WHERE o.order_date > '2023-01-01';

✅ Оптимизированный запрос:

SELECT c.name, o.order_date, p.name AS product
FROM customers c
JOIN orders o ON c.id = o.customer_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE o.order_date > '2023-01-01';

💡 Каждый JOIN увеличивает нагрузку! Включайте только таблицы, которые реально нужны для получения результата.

#QueryOptimization #SQLPerformance

❌ #SQLAntiPattern: Многократные запросы вместо одного

Частая ошибка в коде приложений - множество отдельных запросов вместо одного:

# ❌ Плохо: N+1 запрос
users = db.query("SELECT * FROM users WHERE active = 1")
for user in users:
    orders = db.query(f"SELECT * FROM orders WHERE user_id = {user.id}")
    # Обработка каждого пользователя и его заказов

✅ Правильное решение - один запрос с JOIN:

# ✅ Хорошо: один запрос
results = db.query("""
    SELECT u.*, o.* 
    FROM users u
    LEFT JOIN orders o ON u.id = o.user_id
    WHERE u.active = 1
""")

# Группировка результатов в Python
users_with_orders = {}
for row in results:
    # Логика группировки заказов по пользователям

💡 Проблема N+1 запросов - одна из главных причин медленной работы приложений!

#NPlus1Problem #ApplicationPerformance

🎯 #SQLСобеседование: Вопросы по транзакциям и ACID

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

✅ Что такое ACID?
* Atomicity (Атомарность): транзакция выполняется полностью или не выполняется вообще
* Consistency (Согласованность): БД переходит из одного корректного состояния в другое
* Isolation (Изолированность): параллельные транзакции не влияют друг на друга
* Durability (Долговечность): изменения сохраняются даже при сбоях системы

✅ Уровни изоляции транзакций:
* READ UNCOMMITTED - можно читать незафиксированные изменения (грязное чтение)
* READ COMMITTED - видны только зафиксированные изменения
* REPEATABLE READ - повторное чтение тех же данных дает тот же результат
* SERIALIZABLE - полная изоляция, транзакции выполняются последовательно

✅ Пример использования транзакций:

BEGIN TRANSACTION;
    UPDATE accounts SET balance = balance - 100 WHERE id = 1;
    UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

💡 Знание транзакций демонстрирует понимание основ работы СУБД!

#Транзакции #SQLAdvanced

🎯 #SQLСобеседование: Вопросы по нормализации

Нормализация - обязательная тема на SQL-собеседованиях:

✅ Что такое нормализация?
Процесс организации данных в БД для минимизации избыточности и зависимостей.

✅ Основные нормальные формы:
1NF: Каждая ячейка содержит одно атомарное значение, нет повторяющихся групп
2NF: Соответствует 1NF и все неключевые атрибуты зависят от всего первичного ключа
3NF: Соответствует 2NF и нет транзитивных зависимостей неключевых атрибутов
BCNF: Соответствует 3NF и все детерминанты являются потенциальными ключами

✅ Пример преобразования к 3NF:
Не нормализовано:

Orders(order_id, customer_name, customer_email, product_id, product_name, quantity, price)

В 3NF:

Customers(customer_id, name, email)
Products(product_id, name, price)
Orders(order_id, customer_id, order_date)
OrderItems(order_id, product_id, quantity)

💡 Совет: объясните не только формы, но и практическую пользу нормализации!

#DatabaseDesign #Normalization

#SQLСобеседование: Вопросы по оконным функциям

Оконные функции - признак продвинутого SQL-разработчика:

✅ Что такое оконные функции?
Функции, выполняющие вычисления по набору строк (окну), связанных с текущей строкой.

✅ Основные оконные функции:
- ROW_NUMBER(): порядковый номер строки в окне
- RANK(), DENSE_RANK(): ранжирование с учетом "дырок" и без
- LAG(), LEAD(): доступ к предыдущей/следующей строке
- SUM(), AVG(), COUNT() OVER(): агрегаты по окну

✅ Пример использования:

SELECT 
  product_name,
  category,
  price,
  ROW_NUMBER() OVER(PARTITION BY category ORDER BY price DESC) as price_rank,
  AVG(price) OVER(PARTITION BY category) as avg_category_price,
  price - AVG(price) OVER(PARTITION BY category) as price_diff_from_avg
FROM products;

💡 Знание оконных функций часто отделяет junior от middle-разработчиков!

#WindowFunctions #AdvancedSQL