📂 Напоминалка по SQL Injection (SQLi)!

Например, простая инъекция вроде OR 1=1 может вернуть все данные из таблицы, а blind SQLi позволяет вытаскивать информацию даже тогда, когда приложение не показывает ошибки и результаты запросов.

На картинке — основные типы SQL-инъекций, которые важно знать при работе с базами данных и backend-логикой.

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

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

Как понять, что PostgreSQL работает на устаревшей статистике?

PostgreSQL хранит информацию о последнем сборе статистики:

SELECT relname,
       last_analyze,
       last_autoanalyze,
       n_live_tup
FROM pg_stat_user_tables;

last_analyze — когда статистика обновлялась вручную,
last_autoanalyze — когда это делал autovacuum.

Чтобы быстро найти проблемные таблицы, отсортируем по размеру:

SELECT relname,
       n_live_tup,
       last_analyze,
       last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

Большая таблица + старый last_analyze — оптимизатор работает вслепую.

В таком случае достаточно обновить статистику:

ANALYZE;

Или точечно, для одной таблицы:

ANALYZE orders;

🔥 Это помогает объяснить внезапную деградацию запросов и понять, почему индекс игнорируется.

➡️ SQL Ready | #совет

☕️ StrataScratch — вопросы с собеседований!

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

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

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

☕️ На Хабре вышла подробная статья про автоматизацию развертывания PostgreSQL-кластеров в изолированной инфраструктуре.

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

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

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

☕️ Postgrespro — полная и актуальная документация по PostgreSQL!

SQL-синтаксис, индексы, транзакции, планировщик запросов, репликация, расширения и внутренняя архитектура. Здесь подробно описано не только как писать запросы, но и как база данных работает. Полезно, если используешь Postgres в продакшене или хочешь глубже разобраться в производительности.

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

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

Оконные функции ROW_NUMBER() в SQL — нумерация строк для аналитики!

ROW_NUMBER() присваивает уникальный порядковый номер строкам внутри логического окна. Данные не объединяются в группы, строки остаются как есть — это ключевое отличие от GROUP BY.

Таблица:

payments(id, user_id, amount, created_at)

Нумеруем платежи каждого пользователя. Окно создаётся по user_id, а нумерация идёт по дате от старых к новым:

SELECT id, user_id, amount,
       ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at ASC) AS rn
FROM payments;

PARTITION BY разбивает данные на сегменты (в данном случае — по пользователю). ORDER BY внутри OVER() задаёт, в каком порядке будут присваиваться номера.

Чтобы найти последний платёж каждого пользователя, меняем порядок сортировки на DESC. Самая свежая запись получит номер 1 в своём окне:

WITH t AS (
  SELECT id, user_id, amount,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
  FROM payments
)
SELECT * FROM t WHERE rn = 1;

Здесь используем CTE (WITH), чтобы сначала пронумеровать строки, а затем отфильтровать только нужный номер.

Следующий пример — логины пользователей:

auth_logs(id, user_id, ip, login_at)

Ищем первый вход каждого пользователя с каждого IP:

WITH t AS (
  SELECT id, user_id, ip,
         ROW_NUMBER() OVER (PARTITION BY user_id, ip ORDER BY login_at ASC) AS rn
  FROM auth_logs
)
SELECT * FROM t WHERE rn = 1;

🔥 ROW_NUMBER() подходит, когда нужен номер строки в сегменте, важно выбрать первую/последнюю запись по логике сортировки,требуется топ-N по категориям или пользователям.

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

Генерация фейковых данных для тестов с мгновенной вставкой в любую таблицу!

SQL понимает VALUES как виртуальную таблицу, поэтому можно писать много строк прямо в INSERT:

INSERT INTO users (id, email, name) VALUES
  (1, 'alice@mail.com', 'Alice'),
  (2, 'bob@mail.com',   'Bob'),
  (3, 'carol@mail.com', 'Carol');

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

Хотите протестировать в своем проекте? Создайте таблицу и вставьте строки выше:

CREATE TABLE users (
  id    int PRIMARY KEY,
  email text,
  name  text
);

🔥 Пригодится, когда нужно быстро заполнить таблицу для проверки логики.

➡️ SQL Ready | #совет

❤️ Red Blob Games — полезный сайт для визуального понимания алгоритмов!

Если тебе сложно понять алгоритмы по учебникам — этот ресурс решает проблему. Автор объясняет графы, геометрию, деревья, меши из геймдева через понятные визуализации и интерактивы. Сложные идеи здесь раскладываются на простые шаги.

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

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

Знали, что NOT IN — главный источник тихих багов, если в подзапросе есть NULL?

Этот запрос выглядит логично, но опасен:

WHERE user_id NOT IN (SELECT id FROM users);

Если подзапрос вернёт хотя бы один NULL, условие станет UNKNOWN, и не вернётся ни одной строки.

Правильнее и безопаснее паттерн NOT EXISTS:

WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id);

Он корректно работает при NULL, не ломает логику и читается однозначно.

Хотите повторить? Проверьте разницу сами:

CREATE TABLE users(id int);
INSERT INTO users VALUES (1), (2), (NULL);

Теперь запустите:

SELECT 1 AS test WHERE 3 NOT IN (SELECT id FROM users);

Результат будет пустым.

🔥 А если переписать через NOT EXISTS, логика вернётся в норму.

➡️ SQL Ready | #совет

📂 Напоминалка про Modem vs Router!

Модем отвечает за подключение к провайдеру и получение публичного IP, а роутер управляет локальной сетью: маршрутизирует трафик, выполняет NAT и раздаёт адреса устройствам.

На картинке — ключевые отличия и базовая схема работы.

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

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

Всех с наступающим 2026 годом! 🎄

Поставлю себе цель: набрать более 20 тысяч подписчиков ✍️

Партицирование в оконных функциях — когда нужно работать с топами внутри групп!

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

Представим таблицу:

products(id, category, price)

Нужно выбрать самый дорогой товар в каждой категории, но при этом видеть все колонки строки:

SELECT *
FROM (
    SELECT
        *,
        ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC, id DESC) AS rn
    FROM products
) t
WHERE rn = 1;

PARTITION BY формирует независимые окна для каждой категории.
ROW_NUMBER() нумерует строки внутри каждой партиции, а не по всей таблице.

Если нужны не только первые, а, например, топ-3 в каждой категории:

SELECT id, category, price
FROM (
    SELECT
        id, category, price,
        ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC, id DESC) AS rn
    FROM products
) t
WHERE rn <= 3
ORDER BY category, price DESC;

Тут важно: без PARTITION BY запрос взял бы топ-3 по всей таблице, а не по категориям.

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

Ещё полезный трюк — находить максимум в группе без GROUP BY и JOIN, через коррелированный подзапрос:

SELECT *
FROM products
WHERE price = (
    SELECT MAX(price)
    FROM products p2
    WHERE p2.category = products.category
);

Этот запрос не агрегирует основную таблицу и вернёт несколько строк, если в категории есть товары с одинаковой максимальной ценой (ties).

🔥 Используйте PARTITION BY в оконных функциях, когда логика должна применяться внутри каждой группы независимо, а строки нужно сохранить целиком.

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