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

✍️ 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 | #совет

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

🎄 Новый год - идеальный момент перезапустить себя.

Не “с понедельника”. Не “когда будет время”. А сейчас.

🔥 Мы собрали Telegram-каналы, где только код, практика и самые передовые инструменты, которые используют разработчики прямо сейчас.👇 🖥SQL: t.me/databases_tg 🖥 Базы данных: t.me/sqlhub 🖥 ИИ: t.me/ai_machinelearning_big_data 🖥 Python: t.me/pythonl 🖥 Linux: t.me/linuxacademiya 🖥 C++ t.me/cpluspluc 🖥 Docker: t.me/DevopsDocker 🖥 Хакинг: t.me/linuxkalii 🖥 Devops: t.me/DevOPSitsec 👣 Golang: t.me/Golang_google 🖥 Аналитика: t.me/data_analysis_ml 🖥 Javascript: t.me/javascriptv 🖥 C#: t.me/csharp_ci 🖥 Java: t.me/javatg 👣 Rust: t.me/rust_code 🤖 Нейросети: t.me/vistehno 💼 Актуальные вакансии: t.me/addlist/_zyy_jQ_QUsyM2Vi 📚 Бесплатные ит-книги: https://t.me/addlist/HwywK4fErd8wYzQy Самое лучшее в этом: ты учишься даже тогда, когда “нет времени, просто потому что читаешь правильную ленту.

📂 Напоминалка для работы с алгоритмами выбора лидера в распределённых системах! Например, Raft выбирает лидера через голосование, Paxos использует кворум, а Bully Algorithm назначает лидером узел с максимальным ID. На картинке — 5 базовых алгоритмов leader election, которые используются в распределённых БД и системах координации. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

🖥 SCD2 — хранение истории изменений в таблицах! При прямом UPDATE данные теряют историю: невозможно корректно восстановить состояние сущности на дату или отследить момент изменения. Сегодня в гайде:

• Как моделировать версионные данные через valid_from / valid_to; • Как корректно закрывать предыдущую версию и создавать новую; • Как получать актуальное состояние и исторические срезы без дополнительной логики.

SCD Type 2 хранит каждое изменение как отдельную версию строки с фиксированным интервалом актуальности. ➡️ SQL Ready | #гайд

Слили в телеграмм тонны инфы и отсортировали по каналам 🖥 Курсы & GitHub — 1579ГБ ⌨️ Python — 955ГБ 🤒 OSINT — 315ГБ ☁️ Хакинг & ИБ — 756ГБ 🙃 Linux & Bash — 459ГБ 😦 Работа в IT — 778ГБ 🖥 Общий архив — 2346ГБ ➡️ Практические инструкции, курсы, книги и инструменты.

😎 Сodedokode/pasta — теория + задачи на практике! Репозиторий с понятным и структурированным разбором баз данных на русском языке. Здесь разобраны ключевые концепции SQL для MySQL и PostgreSQL, есть примеры запросов и задачи для самостоятельной работы. Отлично подходит для укрепления базы и подготовки к собеседованиям.

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

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

LEFT JOIN и WHERE — классическая ловушка с NULL! LEFT JOIN используют, когда нужно сохранить строки из левой таблицы, даже если в правой нет совпадений. Но одно неверное условие в WHERE — и LEFT JOIN незаметно превращается в INNER JOIN. Таблицы:

users(id, email)
orders(id, user_id, amount)

Нужно получить всех пользователей и их заказы (если есть):

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

Если у пользователя нет заказов, поля из orders будут NULL — это ожидаемое поведение LEFT JOIN. Теперь типичная ошибка:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Условие в WHERE отфильтровывает строки, где o.amount IS NULL. В результате пользователи без заказов исчезают, и запрос фактически работает как INNER JOIN. Правильный вариант — переносить условия на правую таблицу в ON:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
   AND o.amount > 100;

Теперь: пользователи без заказов остаются в результате, фильтрация применяется только к связанным строкам orders. Если же логика действительно требует убрать пользователей без заказов, тогда честнее писать INNER JOIN:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Так намерение запроса читается однозначно. 🔥 Условия в WHERE применяются после JOIN и могут уничтожить строки с NULL. Условия в ON влияют только на логику связывания таблиц. ➡️ SQL Ready | #практика

⚡ Повысить производительность СУБД или сократить расходы на IT-инфраструктуру? Не нужно выбирать. Selectel расскажет и покажет, как найти баланс на примере собственного сервиса. Подключайтесь к бесплатному вебинару для тех, кто работает с базами данных 🗓 5 февраля, 12:00 📍 Онлайн Вы узнаете: - как работают базы данных на выделенном облачном сервере, - какие особенности архитектуры позволяют повысить производительность сервиса в 10 раз и получить до 1,5 млн IOPS и 7000 Мб/c в облаке, - как клиентам Selectel удается экономить до 47% на IT-инфраструктуре. Регистрируйтесь по ссылке: https://slc.tl/27v33 👉 Чтобы не пропустить новые мероприятия, воркшопы и бесплатные курсы Selectel, подписывайтесь на @selectel_events Реклама. АО "Селектел". erid:2W5zFJj73Gc

❤️ AlgoTree — понятные объяснения алгоритмов, деревьев и графов! Этот сайт помогает анализировать структуры данных: деревья, графы, обходы и множество другого. Здесь нет решений задач или подготовкой к собеседованиям, упор именно на понимание того, как и почему всё устроено. Материал подается последовательно и концептуально, поэтому хорошо подходит даже новичкам. 📌 Оставляю ссылочку: algotree.org ➡️ SQL Ready | #ресурс

🖥 Ищем пересекающиеся бронирования! В системах бронирования одна из частых ошибок - это пересечение интервалов, когда один и тот же ресурс оказывается занят сразу несколькими пользователями. Сегодня в задаче:

• Сравним бронирования одного ресурса между собой, не создавая дубликатов; • Проверим пересечение временных интервалов с помощью канонического условия; • Получим список конфликтующих бронирований, которые система должна блокировать.

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

Как получить «последнюю запись на группу»? Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с ROW_NUMBER(), хотя Postgres умеет проще:

SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;

DISTINCT ON оставляет первую строку в рамках группы, а порядок задаётся через ORDER BY:

ORDER BY user_id, created_at DESC

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

ORDER BY user_id, created_at DESC, id DESC

Если нужно выбрать конкретные поля и избежать SELECT *, просто укажите нужные колонки:

SELECT DISTINCT ON (user_id)
       user_id, id, created_at
FROM orders
ORDER BY user_id, created_at DESC, id DESC;

Выражения из DISTINCT ON (...) обязаны быть левым префиксом ORDER BY, иначе Postgres выдаст ошибку. 🔥 Такой запрос часто читается проще, чем ROW_NUMBER(), и при подходящем индексе (user_id, created_at DESC, id DESC) может давать отличный план выполнения. ➡️ SQL Ready | #совет