SQL Ready | Базы Данных

Индексы и ORDER BY DESC без лишней сортировки! Многие думают, что для ORDER BY … DESC нужен отдельный DESC-индекс — но это не всегда так. В PostgreSQL обычный B-tree индекс:

CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at);

уже может использоваться для ORDER BY created_at DESC через backward scan, без дополнительной сортировки. Если нужен смешанный порядок (например (user_id ASC, created_at DESC)), тогда имеет смысл явно указать направление:

CREATE INDEX idx_orders_user_created_desc
ON orders (user_id, created_at DESC);

🔥 В таких случаях PostgreSQL сможет читать данные сразу в нужном порядке. ➡️ SQL Ready | #совет

Роден нанял бы себе ИИ-агента 💯 Ещё пару лет назад ценность инженера была в технических навыках. Сейчас — в том, как он выстраивает систему, которая работает за него или даже целую команду. Примерно как Роден 😅 Да, тот самый скульптор XIX века. Он не вырезал каждую скульптуру сам, а строил мастерскую, где идея остаётся за ним, а исполнение масштабируется. С ИИ происходит то же самое. Лучшие команды собирают процессы, где агенты подхватывают задачи, делают работу и возвращают результат — остаётся только проверить. Вот вам простой тест (подсмотрел у Дмитрия Бороздина): — у вас есть документация, где хранится весь контекст? — проводите тесты ИИ-агентов? — работаете с логами и метриками, чтобы отслеживать ошибки? Если хотя бы на один вопрос ответили «нет» — ваша мастерская, скорее всего, работает некорректно. Я периодически читаю Дмитрия — он много пишет об ИИ в ритейле: как влияет на продажи, клиентский опыт и экономику интернет-магазинов. Если тема откликается, вот канал: https://t.me/+P3CyHSaACRU3Nzgy?erid=2W5zFHq1vVw 👈

📂 Напоминалка по SQL вопросам! Например, WHERE фильтрует строки до агрегации, а HAVING — уже после GROUP BY. На картинке — основные конструкции: разница между WHERE и HAVING, оконные функции против обычной агрегации, а также основы партицирования для больших таблиц. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

UPDATE ... FROM в PostgreSQL: как обновлять данные из другой таблицы и не поймать скрытые дубли! Задача, которая встречается постоянно: обновить таблицу по данным из другой. Например, проставить клиентам дату последнего заказа. Есть таблицы:

customers(id, last_order_at)
orders(id, customer_id, created_at)

Интуитивный вариант:

UPDATE customers c
SET last_order_at = o.created_at
FROM orders o
WHERE o.customer_id = c.id;

Запрос выполнится, но если у клиента несколько заказов — возникает вопрос: какая именно дата попадёт в last_order_at? Ответ — это не гарантируется. Запрос корректен синтаксически, но логически небезопасен. Если JOIN даёт несколько строк для одной записи в customers, PostgreSQL не гарантирует, какую строку он использует при обновлении. Поэтому сначала нужно свести соответствие к одной строке на клиента. Через агрегат:

UPDATE customers c
SET last_order_at = t.max_created_at
FROM (
    SELECT
        customer_id,
        MAX(created_at) AS max_created_at
    FROM orders
    GROUP BY customer_id
) t
WHERE t.customer_id = c.id;

Теперь для каждого клиента ровно одна строка — обновление становится детерминированным. Вариант через DISTINCT ON:

UPDATE customers c
SET last_order_at = t.created_at
FROM (
    SELECT DISTINCT ON (customer_id)
        customer_id,
        created_at
    FROM orders
    ORDER BY customer_id, created_at DESC
) t
WHERE t.customer_id = c.id;

Здесь тоже выбирается одна строка на клиента за счёт сортировки. Если возможны одинаковые created_at, лучше добавить tie-breaker:

ORDER BY customer_id, created_at DESC, id DESC

Коррелированный подзапрос:

UPDATE customers c
SET last_order_at = (
    SELECT MAX(o.created_at)
    FROM orders o
    WHERE o.customer_id = c.id
);

Плюс: гарантированно одно значение. Нюанс: обновятся все строки в customers, и у клиентов без заказов будет NULL. Пример ловушки:

UPDATE customers c
SET last_order_at = t.created_at
FROM (
    SELECT customer_id, created_at
    FROM orders
) t
WHERE t.customer_id = c.id;

С виду безопасно, по факту — та же проблема: соответствие не уникально. Практическая проверка: замените UPDATE на SELECT с тем же JOIN и посмотрите, есть ли дубли:

SELECT c.id, t.*
FROM customers c
JOIN ...

Если дубли есть — такой UPDATE уже небезопасен. Про индексы:

CREATE INDEX idx_orders_customer_created
ON orders (customer_id, created_at);

Помогает и для MAX, и для ORDER BY. Итог: UPDATE ... FROM — крутой инструмент, но он не проверяет однозначность соответствия. 🔥 Если JOIN возвращает несколько строк на одну обновляемую запись, результат не гарантируется. Сначала фиксируем одну строку на ключ — потом обновляем. ➡️ SQL Ready | #практика

💙 Он купил Lexus LX 570 за месяц цена которого от 8,1 до 16 миллионов рублей , просто инвестируя в телеграмм проект с телефона Отзыв Артема: Я полтора месяца назад не имел сбережений и работал получая до 70 тысяч в месяц. В один день начальник меня оштрафовал за то что я с температурой 40 не вышел на работу. Я понял что нужно что-то менять, и я не знаю как это работает но в этот же день листая телеграм я наткнулся на пост что какая-то Анастасия помогает заработать другим. Моя первая реакция была такой "🤣🤣🤣" думаю ну развод какой-то, а потом я как Ах**л с того что мне реально поступила месячная зп за день. Позвонил начальнику и сказал иди ты на*** с своей работой. Мы проверили информацию, и Анастасия имеет успешный проект и coтрудничает со всеми желающими, помогая увеличить свой кaпитал.Переходи, и следуй инструкциям. И забирай свои 70.000 рублей уже в первый день ⚠️Ссылка на канал скоро закроется - https://t.me/+rYORmG8PZPhhMDYy

😎 SQL Tutorials — структурированный набор материалов! Здесь собраны конспекты, шпаргалки и учебные PDF по всем ключевым темам: от базовых запросов до сложных конструкций и оптимизации. Отдельно выделяется наличие большого количества материалов для подготовки к собеседованиям, сотни вопросов и разборов.

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

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

✍️ SQL for Beginners — база SQL с нуля на практике! Репозиторий с материалами для изучения SQL с самого начала: здесь разбираются основы работы с базами данных, синтаксис запросов, JOIN-ы, фильтрация, агрегации и структура таблиц. Формат обучения построен вокруг практики, примеры запросов, задания и объяснения помогают не просто читать теорию, а сразу писать код.

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

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

Полуинтервалы вместо BETWEEN для корректных и быстрых диапазонов! BETWEEN кажется удобным, но он включает обе границы, из-за чего легко ловятся баги на датах и времени, особенно с timestamp:

WHERE created_at BETWEEN '2025-01-01' AND '2025-01-31'

Такой код пропустит всё, что позже '2025-01-31 00:00:00', и это одна из самых частых, незаметных ошибок в аналитике:

WHERE created_at >= '2025-01-01'
AND created_at < '2025-02-01'

Полуинтервал [start, end) работает предсказуемо для любых типов времени, не ломается на миллисекундах и хорошо ложится на индексы:

WHERE ts >= now()
AND ts < now() + interval '1 day'

🔥 Этот паттерн используют в биллинге, аналитике, логах и любых системах, где важна точность временных границ. ➡️ SQL Ready | #совет

🖥 Стажировки и вакансии для SQL разработчиков и администраторов. - Вакансии которых нет на джоб-агрегаторах - Только прямые контакты HR в Telegram 👉 @jobs_sql 🤖 ML & DS 👩‍💻 DevOps 👨‍✈️ ИБ & OSINT 👣 Go 👩‍💻 Mobile 👩‍💻 C# 👩‍💻 Node.js 👩‍💻 Python 🔎 QA 👩‍💻 Java 👩‍💻 UX/UI 👩‍💻 Frontend 🖼️ PHP 📋 Analyst 💼 1C 🖥 SQL 👩‍💻 IT HR Пока другие листают джоб-сайты — ты уже пишешь HR в Telegram.

📂 Базовые структуры данных и их применение в системах! Например, B-Tree используется в индексах для ускорения поиска, а Hash Table — в механизмах join’ов и кэширования. На картинке — ключевые структуры данных и типичные сценарии их использования в реальных системах и базах данных. Сохрани, чтобы держать под рукой! ➡️ SQL Ready | #ресурс

❤️ SQL Anti-Patterns — ошибки в SQL, которые допускают почти все! Этот репозиторий разбирает типичные ошибки и плохие практики в SQL, с которыми сталкиваются разработчики в реальных проектах. Здесь показано, как не стоит писать запросы, и даются более правильные и эффективные альтернативы. Отлично подходит для оптимизации запросов и подготовки к собеседованиям.

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

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

LIMIT без ORDER BY — почему результат нестабилен! Есть таблица:

orders(id, customer_id, amount, created_at)

И вот такой запрос:

SELECT * FROM orders LIMIT 10;

Интуитивно хочется думать, что это первые 10 или последние 10. На деле — это просто неопределённые 10 строк в неопределённом порядке. Без ORDER BY база не обязана возвращать данные в каком-то фиксированном порядке. Сегодня это один набор строк, завтра — другой. Особенно если поменялся план выполнения или появился индекс. Типичный кейс — хочу последние заказы:

SELECT * 
FROM orders 
ORDER BY created_at DESC 
LIMIT 10;

Уже лучше: теперь это 10 самых новых по created_at. Но тут есть тонкость — если несколько строк имеют одинаковый created_at, порядок между ними не детерминирован. Иногда это всплывает в самых неожиданных местах (например, в пагинации). Поэтому обычно добавляют второй критерий:

SELECT * 
FROM orders 
ORDER BY created_at DESC, id DESC 
LIMIT 10;

Если id уникальный — результат становится детерминированным для текущего среза данных. Где это особенно критично: пагинация, API, отчёты, кэш. Без стабильного порядка начинаются фантомные баги: строки то появляются, то исчезают, то дублируются. OFFSET и его ограничения:

SELECT * 
FROM orders 
ORDER BY created_at DESC, id DESC 
LIMIT 10 OFFSET 20;

Добавились новые записи — и страницы уже не совпадают с тем, что было секунду назад. Поэтому в проде чаще используют keyset pagination:

SELECT * 
FROM orders 
WHERE (created_at, id) < ('2026-01-10', 1050)
ORDER BY created_at DESC, id DESC 
LIMIT 10;

Фактически: дай следующие записи после этой точки. Работает быстрее и ведёт себя предсказуемо при изменениях данных (Важно: синтаксис с (col1, col2) поддерживается не во всех СУБД; универсальный вариант — через OR.) И ещё частая ошибка:

SELECT * 
FROM orders 
ORDER BY created_at 
LIMIT 1;

Кажется, что это последняя запись, а по факту — самая старая (по умолчанию используется ASC в большинстве СУБД). 🔥 Вся суть: LIMIT отвечает только за количество. Порядок — это всегда ORDER BY. Без составного индекса (created_at, id) такие запросы на больших таблицах начинают ощутимо тормозить. ➡️ SQL Ready | #практика

🌅 На берегу Онежского озера в Карелии — бутик-отель «Заонежье» Здания из северного дерева и лемеха гармонично вписаны в ландшафт Русского Севера. Для гостей созданы 13 видовых номеров и 4 гостевых дома с каминами, ресторан «Руна» с локальной кухней, пирс, панорамный зал и экотропы. Любители активного отдыха могут отправиться на Кижи, порыбачить, выйти на каяке или катере, прокатиться на велосипеде по окрестностям или покорить местные пейзажи на квадроцикле. 🏆 Проект отмечен премиями LIV Hospitality Design Awards, Archiwood, ADD Awards и Rethinking The Future Awards. Первозданная природа и настоящий комфорт в одном месте. 🔗 zaonezhie.com · Telegram

📂 Напоминалка по масштабированию баз данных! Например, индексы ускоряют поиск данных, а шардинг позволяет распределять нагрузку между несколькими серверами. На картинке — основные стратегии масштабирования, которые используются в реальных системах. Сохрани, чтобы держать под рукой! ➡️ SQL Ready | #ресурс

Использование расширенной статистики для повышения точности планировщика! Бывает, что запрос очевидный, индексы есть, но PostgreSQL всё равно выбирает Seq Scan, потому что считает условия независимыми и сильно ошибается в кардинальности:

CREATE STATISTICS s_orders (dependencies)
ON user_id, status
FROM orders;

Extended statistics позволяют оптимизатору учитывать зависимости между колонками, например что у конкретного user_id почти всегда один и тот же status:

ANALYZE orders;

После сбора статистики PostgreSQL начинает правильно оценивать селективность комбинации условий, а не перемножать вероятности как будто они независимы:

EXPLAIN ANALYZE SELECT ...

🔥 Не меняешь код и индексы, но кардинально улучшаешь планы выполнения. ➡️ SQL Ready | #совет

👨👨👨👨👨👨👨👨👨👨 Каналы с Junior IT вакансиями и стажировками Подписывайся и забирай свой оффер 🤘 1. Стажировки и вакансии по России и миру 2. IT вакансии по СНГ 3. IT стажировки по СНГ 4. ИИ-ассистент для автооткликов 5. IT стажировки и волонтерства 6. IT стажировки в топовых компаниях мира 7. Удалённые IT вакансии и стажировки 8. Python вакансии и стажировки 9. БИГТЕХ вакансии и стажировки 10. Design вакансии и стажировки 11. QA вакансии и стажировки 12. Junior вакансии и стажировки 13. Frontend вакансии и вопросы собесов 14. Вакансии и стажировки для аналитиков 15. Вакансии в русских стартапах за границей 16. Вакансии и стажировки для DevOps 17. Вакансии, которых нет на ХХ.РУ

🖥 Напоминалка по SQL-командам! Например, GRANT даёт пользователю права на таблицу, а ROLLBACK отменяет изменения в рамках транзакции. На картинке — 5 групп SQL-команд: от определения структуры до управления доступом. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

CHECK-ограничения — валидация данных на уровне базы! CHECK позволяет задать правила, которым обязана соответствовать каждая строка в таблице. Это удобно, когда нужно гарантировать корректные значения без сторонней логики. Представим, что мы хотим убедиться, что цена товара всегда больше нуля:

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  name TEXT,
  price NUMERIC(10,2),
  CHECK (price > 0)
);

Теперь добавим ограничение, чтобы процент скидки был в пределах от 0 до 100:

ALTER TABLE discounts
ADD CONSTRAINT percent_range_chk
CHECK (percentage BETWEEN 0 AND 100);

И создадим таблицу событий, где дата начала всегда должна быть раньше даты окончания:

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  starts_at TIMESTAMP,
  ends_at TIMESTAMP,
  CHECK (starts_at < ends_at)
);

🔥 Но помните, что CHECK проверяет только вставляемые или обновлённые строки. Если вы добавляете ограничение в таблицу с данными, указывайте NOT VALID, чтобы временно обойти проверку. ➡️ SQL Ready | #практика

Ваши дашборды грузятся по минуте? SQL-запросы «падают» на продакшене, а бизнес требует отчеты «еще вчера»?

Узкое место — не мощность сервера, а эффективность кода и архитектуры запросов.

Прокачайте скорость для себя и команды - получите бесплатно тренинг «Аналитика без тормозов» от Георгия Семенова, руководителя из Яндекс Вы узнаете: ✅ Методы ускорения запросов и дашбордов, применимые к любой СУБД ✅ Специфические нюансы оптимизации, которые отличают middle от senior. Но это не всё. Мы понимаем: результат дает прокачка всей команды и внедрение знаний в конкретные рабочие задачи. Симулейтив предлагает корпоративное обучение под ключ: ✅Преподаватели-практики из “биг-теха” адаптируют программу под ваши задачи ✅Выгода до 30% при пакетном команды ✅Рамочный договор и помощь с компенсацией Примените знания уже сегодня, а затем внедрите её в работу всего отдела аналитики - чтобы ваши процессы полетели! Забрать тренинг Реклама. ООО "АЙТИ РЕЗЮМЕ". ИНН 4025460134. erid: 2W5zFJpk4QR

😎 Отыскал для вас LabEx — прокачка SQL в формате игры! Вместо скучной теории — реальные задания, которые решаешь прямо в браузере. Всё с подсказками, примерами и моментальной проверкой. Отлично, чтобы быстро вкатиться в SQL или прокачать скилл. 📌 Оставляю ссылочку: labex.io ➡️ SQL Ready | #ресурс