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

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

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

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

➡ SQL Ready | #ресурс

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

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

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

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

➡️ 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 by Example — SQL-шпаргалка с примерами запросов!

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

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

➡️ 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 | #практика

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

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

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

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

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

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

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

➡️ 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 | #практика

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

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

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

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

➡️ 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 Cheat Sheet — удобнейшая и информативная шпаргалка!

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

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

➡️ 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 | #практика

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

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

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

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