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.

😎 На Хабре вышла полезнейшая статья про репликацию в 1С и реальные нагрузки на СУБД! В этой статье: • Разбирается, как вынести тяжёлые отчёты 1С с мастер-базы на реплику; • Показывается настройка репликации PostgreSQL/Tantor DB под реальные сценарии 1С; • Анализируются узкие места, задержки репликации и влияние отчётных запросов; • Даются результаты нагрузочного тестирования и выводы, которые можно применить в системах.

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

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

ORDER BY в подзапросах: почему порядок не гарантируется! ORDER BY управляет порядком строк только в финальном результате запроса. В подзапросах и CTE он не гарантирует порядок строк, если не используется вместе с ограничением количества возвращаемых данных. Причина в том, что оптимизатор может свободно менять план выполнения, пока итоговый результат формально остаётся корректным. Таблица событий:

events(id, user_id, created_at)

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

SELECT *
FROM (
    SELECT *
    FROM events
    ORDER BY created_at DESC
) t;

Несмотря на явный ORDER BY внутри подзапроса, внешний запрос не содержит сортировки. Это означает, что порядок строк на выходе не определён, и СУБД имеет право проигнорировать внутреннюю сортировку как не влияющую на результат. Корректный вариант — сортировать во внешнем запросе:

SELECT *
FROM events
ORDER BY created_at DESC;

Именно этот ORDER BY гарантирует порядок строк, который получит клиент или приложение. Когда ORDER BY в подзапросе имеет смысл — он становится значимым только вместе с ограничением:

SELECT *
FROM (
    SELECT *
    FROM events
    ORDER BY created_at DESC
    LIMIT 10
) t
ORDER BY created_at DESC;

В этом случае сортировка в подзапросе используется для выбора нужных строк, а не для их отображения. Внутренний ORDER BY определяет, какие именно 10 строк попадут в подзапрос, а внешний ORDER BY задаёт порядок финального результата. Аналогичный принцип работает с оконными функциями:

SELECT id, user_id, created_at
FROM (
    SELECT
        id,
        user_id,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM events
) s
WHERE rn = 1;

Здесь ORDER BY влияет на вычисление ROW_NUMBER, то есть на логику нумерации строк внутри окна, но не определяет порядок вывода строк в результирующем наборе. 🔥 ORDER BY — это про порядок выдачи результата, а не про порядок хранения данных. Без внешнего ORDER BY СУБД не обязана возвращать строки в каком-либо определённом порядке. ➡️ SQL Ready | #практика

Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает? Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗 ✓ Как научиться отвлекаться от работы и отдыхать? ✓ Как совместить кучу рабочих задач и время с семьей? ✓ Как справиться с прокрастинацией? ✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит? Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни! Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии: 👉 https://t.me/+1JwcbmRaKrFlZmQy

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

Частая проблема в аналитике и BI - таблицы с десятками колонок? Пока колонок три это может быть терпимо. Когда их становится двадцать и больше, запросы, джоины и графики начинают разваливаться. UNPIVOT позволяет превратить колонки в строки на уровне SQL, без переписывания данных и логики приложения (синтаксис зависит от СУБД):

UNPIVOT (value FOR metric IN (views, clicks))

На выходе получается универсальная структура metric / value, которая хорошо ложится в агрегации, фильтры и визуализации BI. Полезно, когда нужно сравнивать метрики между собой или передавать данные в BI без кастомной логики:

WHERE metric IN ('views', 'orders')

🔥 Один запрос - десятки метрик и минимум изменений при росте отчёта (новые метрики просто добавляются в список UNPIVOT). ➡️ SQL Ready | #совет

👨👨👨👨👨👨👨👨👨👨 Каналы с IT мероприятиями Подписывайся, чтобы не пропустить 🤘 1. IT мероприятия для стажеров и студентов 2. IT мероприятия по РФ 3. IT мероприятия и хакатоны 4. Бесплатные IT мероприятия 5. IT мероприятия онлайн 6. IT мероприятия Москва 7. IT мероприятия Санкт-Петербург

☕️ PGExercises — тренажер с различными задачами для обучения! Если хочешь не просто учить синтаксис, а писать реальные запросы и практиковаться. Это отличный способ закрепить знания по выборкам, фильтрации, сортировке, условиям и множеству других тем, особенно если готовишься к собесам. 📌 Оставляю ссылочку: pgexercises.com ➡️ SQL Ready | #ресурс

LATERAL — коррелированные подзапросы! Часто бывает нужно для каждой строки основной таблицы взять одну лучшую связанную строку - последнюю, первую, максимальную, минимальную, валидную. Обычно это делают через оконки, CTE или GROUP BY + JOIN, что сложно читать и часто ломается при расширении логики:

LEFT JOIN LATERAL (...)

Выполняет подзапрос для каждой строки слева, подставляя её значения.

ORDER BY created_at DESC
LIMIT 1

Гарантирует, что ты берёшь именно нужную запись:

ON true

Потому что связь уже внутри подзапроса, JOIN тут формальность. 🔥 Это отличный инструмент, когда нужна одна зависимая строка на родителя ➡️ SQL Ready | #совет

WHERE vs HAVING — фильтрация строк и фильтрация групп! В SQL иногда путают WHERE и HAVING, потому что внешне они решают похожую задачу — отфильтровать результат. На практике это два разных этапа выполнения запроса с разной семантикой. Представим таблицу заказов:

orders(id, customer_id, amount)

Нужно выбрать заказы дороже 100. Корректный и очевидный вариант:

SELECT *
FROM orders
WHERE amount > 100;

WHERE применяется до агрегации и фильтрует отдельные строки исходной таблицы. Теперь другая задача: найти клиентов, у которых сумма всех заказов больше 1000. Интуитивная, но неверная попытка:

SELECT customer_id, SUM(amount) AS total_amount
FROM orders
WHERE SUM(amount) > 1000
GROUP BY customer_id;

Этот запрос некорректен: агрегатные функции не могут использоваться в WHERE, потому что на момент применения WHERE агрегатов ещё не существует. Правильный вариант — HAVING:

SELECT customer_id, SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id
HAVING SUM(amount) > 1000;

HAVING применяется после GROUP BY и фильтрует уже сформированные группы. Важно понимать разницу по этапам: WHERE — фильтрует строки до группировки; GROUP BY — формирует группы; HAVING — фильтрует группы; SELECT — формирует итоговый результат. Частая оптимизационная ошибка — переносить условия из WHERE в HAVING без необходимости:

SELECT customer_id, SUM(amount)
FROM orders
GROUP BY customer_id
HAVING amount > 100;

Такой запрос либо не выполнится, либо будет логически неверным: amount — это поле строки, а HAVING работает с группой. Корректный и оптимальный вариант — комбинировать:

SELECT customer_id, SUM(amount) AS total_amount
FROM orders
WHERE amount > 100
GROUP BY customer_id
HAVING SUM(amount) > 1000;

Здесь: WHERE отсекает мелкие заказы до агрегации (меньше данных); HAVING проверяет условие на уровне группы. 🔥 Используй WHERE для фильтрации строк и HAVING — только для условий на агрегаты и группы. Это влияет не только на корректность, но и на производительность запроса ➡️ SQL Ready | #практика

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

✍️ QOMP — квиз для проверки знаний и закрепления навыков! Небольшой, но ёмкий квиз, который проверяет логику работы SQL-запросов. Вопросы заставляют подумать: как реально отработает запрос, где скрыта ошибка и почему результат не такой, как ожидаешь. Отлично подходит для самопроверки и подготовки к собеседованиям. 📌 Оставляю ссылочку: qomp.club ➡️ SQL Ready | #ресурс

🖥 MySQL: работа со строками! Шпаргалка по строковым функциям MySQL для повседневной работы. Разбор приёмов вычисления длины строк, извлечения подстрок, поиска значений, управления регистром и правилами сравнения. Полезно для валидации данных, сортировок, фильтрации, миграций и тонкой настройки запросов без изменения схемы БД. ➡️ 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. Вакансии, которых нет на ХХ.РУ

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

NULL и сравнения — почему = и <> с NULL не работают! NULL в SQL — не значение, а его отсутствие. Из-за этого любые обычные сравнения с NULL ведут себя не так, как ожидают, и часто ломают фильтрацию. Таблица:

users(id, email, deleted_at)

Нужно выбрать неудалённых пользователей. Типичный, но неправильный запрос:

SELECT *
FROM users
WHERE deleted_at = NULL;

Запрос выполнится, но вернёт 0 строк. Почему так — SQL выражение:

deleted_at = NULL

никогда не бывает TRUE. Любое сравнение с NULL (=, <>, <, >) возвращает UNKNOWN, а WHERE пропускает только TRUE. То же самое с отрицанием:

WHERE deleted_at <> NULL;

Результат — тоже пусто. Правильный способ — IS NULL:

SELECT *
FROM users
WHERE deleted_at IS NULL;

И обратное условие:

SELECT *
FROM users
WHERE deleted_at IS NOT NULL;

IS NULL и IS NOT NULL — всегда возвращают TRUE или FALSE, никогда UNKNOWN. Частая скрытая ошибка в составных условиях:

WHERE status = 'active'
  AND deleted_at <> '2026-01-01'

Если deleted_at равен NULL, всё выражение становится UNKNOWN, и строка отбрасывается, даже если status = 'active'. Корректная проверка «не удалён»:

WHERE status = 'active'
  AND deleted_at IS NULL

Важно помнить про OR:

WHERE role = 'admin'
   OR deleted_at IS NULL

Здесь логика работает ожидаемо, потому что IS NULL не возвращает UNKNOWN, а значит выражение может стать TRUE. 🔥 Практические правила: = и <> с NULL не работают в WHERE; любой UNKNOWN в WHERE — строка отбрасывается. Если строка пропала из результата — первым делом проверяй условия с NULL ➡️ SQL Ready | #практика

Совет на 2026 год — освойте ВАЙБ-КОДИНГ. ИИ уже пишет код, чинит баги, генерит тесты и документацию быстрее и качественнее любой команды айтишников И те, кто научится вайбкодить сейчас, будут зарабатывать в разы больше тех, кто всё ещё делает всё вручную Разобраться в этом с нуля поможет канал Вайб-кодинг. Там простым языком разбирают, какие инструменты действительно стоит использовать, как собирать проекты от идеи до релиза и что сейчас актуально в вайбкодинге Подписывайтесь, нас уже 13 тысяч: @vibecoding_tg

Знали, что в SQL можно получить несколько уровней агрегации за один проход по данным? Частая задача - посчитать метрики сразу на нескольких уровнях: по стране и статусу, только по стране и общий итог. Обычно для этого пишут несколько SELECT и склеивают их UNION ALL:

SELECT country, status, COUNT(*) FROM orders GROUP BY country, status
UNION ALL
SELECT country, NULL, COUNT(*) FROM orders GROUP BY country
UNION ALL
SELECT NULL, NULL, COUNT(*) FROM orders;

GROUPING SETS позволяет описать все нужные уровни агрегации в одном GROUP BY:

GROUP BY GROUPING SETS ((country, status), (country), ())

Каждая скобка - отдельный уровень агрегации. PostgreSQL делает это за один проход по данным, без лишних сканов. Строка с пустыми скобками () - это глобальный итог. Колонки, которые не участвуют в текущем уровне, приходят как NULL:

(country = NULL, status = NULL)

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