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

📂 Напоминалка по SQL Injection (SQLi)! Например, простая инъекция вроде OR 1=1 может вернуть все данные из таблицы, а blind SQLi позволяет вытаскивать информацию даже тогда, когда приложение не показывает ошибки и результаты запросов. На картинке — основные типы SQL-инъекций, которые важно знать при работе с базами данных и backend-логикой. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

🖥 Ищем клиентов без единого заказа — полезный приём для выявления неактивных пользователей и повышения конверсии! Цель — найти всех зарегистрированных пользователей, которые так и не оформили ни одного заказа. Это поможет вернуться к ним с акциями или напоминаниями. Основные моменты:

• LEFT JOIN — соединяем таблицы, чтобы сохранить всех клиентов, даже тех, у кого нет заказов. • WHERE o,id IS NULL — отбираем только тех, для кого заказов не найдено. • SELECT — выводим имя, email и дату регистрации.

➡ SQL Ready | #задача

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

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

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

NULL и NOT IN — тонкость SQL, приводящая к логическим ошибкам! При использовании NOT IN в SQL можно получить логически неверный результат без ошибок выполнения. Причина — трёхзначная логика и наличие NULL в данных. Представим таблицы:

customers(id)
orders(id, customer_id)

Нужно найти клиентов, у которых нет заказов. Интуитивный вариант:

SELECT id
FROM customers
WHERE id NOT IN (
    SELECT customer_id
    FROM orders
);

Если подзапрос возвращает хотя бы одно значение NULL, результат этого запроса будет пустым, даже если клиенты без заказов существуют. Это происходит потому, что NOT IN сводится к серии сравнений, а любое сравнение с NULL возвращает неопределённый результат. Попытка исправить ситуацию фильтрацией:

SELECT id
FROM customers
WHERE id NOT IN (
    SELECT customer_id
    FROM orders
    WHERE customer_id IS NOT NULL
);

Формально запрос корректен, но требует постоянного контроля и легко ломается при изменении подзапроса. Надёжный вариант — использовать NOT EXISTS:

SELECT c.id
FROM customers c
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);

NOT EXISTS корректно обрабатывает NULL и предназначен именно для проверок отсутствия связанных строк. 🔥 Используй NOT EXISTS для анти-джойнов и проверок отсутствия данных, а NOT IN — только при полном контроле результата подзапроса. ➡️ SQL Ready | #практика

Ты разбираешься в сложных системах: код, архитектура, алгоритмы — всё логично. А с девушками — хаос. Работа из дома. Коллеги — такие же парни. Дни между ноутом и доставкой. Ты не бедный, не глупый, не урод. Но: — метчей нет — переписки игнорят — нормальных свиданий нет — девушки, которые реально нравятся, игнорят Бесит не отсутствие секса. Бесит, что ты не понимаешь правил игры. Ты привык к ТЗ и алгоритмам, а тут — сплошной рандом. Правда простая: женщины — это другая система. Правила есть, но их никто не объясняет. Я разложил знакомства по шагам: — где знакомиться айтишнику — что писать без кринжа — как вести себя на свидании Если ты устал угадывать и хочешь понимать — всё в канале «Творчество чувств». Важное уже в закрепе 👇 👉 https://t.me/+jcIySXnzR0o4ODBi

Условный UPSERT: как не обновлять строки без изменений? Обычный UPSERT обновляет строку всегда, даже если данные не изменились — это лишние блокировки, WAL и autovacuum. PostgreSQL позволяет сделать условный UPDATE прямо в ON CONFLICT:

ON CONFLICT (id) DO UPDATE
...
WHERE users.email IS DISTINCT FROM EXCLUDED.email
   OR users.name  IS DISTINCT FROM EXCLUDED.name;

Если данные совпадают — UPDATE не выполняется вообще. EXCLUDED — это “новая” версия строки, users.* — текущая версия в таблице.

users.col IS DISTINCT FROM EXCLUDED.col

🔥 Корректно работает даже с NULL и не попадает в ловушки трёхзначной логики. ➡️ SQL Ready | #совет

🏆 Победители номинации «Лучшие IT-каналы» Мы собрали каналы, которые доказали: учиться можно интересно, эффективно и бесплатно. Здесь — тысячи реальных вопросов с собесов, курсов и материалов для тех, кто стремится стать профессионалом. Выбирай направление: 👩‍💻 C# 🤖 DS/ML 👩‍💻 C/C++ 😀 1C 👩‍💻 Java 👩‍💻 Python 🖥 PHP 🖥 Frontend 👣 Rust 👣 Golang 👩‍💻 Node.js 💻 DevOps 👩‍💻 QA 👩‍💻 Android 🖥 BA/SA 👩‍💻 Game Dev 👩‍💻 iOS 👨‍💻 Вакансии База обновляется еженедельно — всегда актуальные вопросы с последних собеседований, курсы и материалы. 📌 Подпишись, чтобы не потерять!

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

FILTER в агрегатных функциях PostgreSQL! В аналитических запросах часто нужно посчитать несколько показателей из одной таблицы. В PostgreSQL для этого есть FILTER, позволяющий задавать условия отдельно для каждой агрегатной функции, не влияя на весь запрос. Представим таблицу заказов:

orders(id, customer_id, amount, status)

Посчитаем общее количество заказов и количество завершённых:

SELECT
    COUNT(*) AS total_orders,
    COUNT(*) FILTER (WHERE status = 'completed') AS completed_orders
FROM orders;

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

SELECT
    COUNT(*) AS total_orders,
    COUNT(*) FILTER (WHERE status = 'completed') AS completed_orders,
    COUNT(*) FILTER (WHERE status = 'canceled')  AS canceled_orders,
    SUM(amount) FILTER (WHERE status = 'completed') AS completed_amount
FROM orders;

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

AVG(amount) FILTER (WHERE status = 'completed')
MAX(amount) FILTER (WHERE status = 'completed')
MIN(amount) FILTER (WHERE status = 'completed')

🔥 Важно помнить: FILTER работает только с агрегатными функциями и применяется внутри SELECT, дополняя, а не заменяя WHERE и GROUP BY. ➡️ SQL Ready | #практика

👩‍💻 Программирование — В С Ё В 2025 году на кодинге уже не вывезешь, перспектива года - Информационная Безопасность. Ловите полезные каналы, которые помогут ворваться в новое направление. 👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля 👍 Белый Хакер — Свежие новости из мира ИБ 😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг 👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям 📂 Вступай и изучай новое направление!

😎 SQL Style Guide — супер полезный репозиторий для освоения языка! Практичный ресурс по написанию SQL: как оформлять SELECT, JOIN, CTE, подзапросы и имена таблиц, чтобы запросы были понятными, поддерживаемыми и удобными для работы в команде. Подходит для любых СУБД и реально упрощает работу и учебу.

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

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

🖥 GROUPING SETS — несколько отчётов в одном запросе! В аналитике часто нужно считать данные сразу на нескольких уровнях: детализация, промежуточные итоги и общий результат. GROUPING SETS позволяет описать эту структуру напрямую. Сегодня в гайде:

• Как считать несколько уровней агрегации за один проход по данным; • Как отличать строки-итоги от обычных данных; • Почему такой подход проще поддерживать и масштабировать.

Приём, который делает отчёты чище, быстрее и предсказуемее при росте требований. ➡️ SQL Ready | #гайд

Ищу 10 человек, чтобы собирали чат-ботов по шаблону, как пазлы. ЗП: от 5-9000₽ за вечер. Занятость: 3-4 часа в день. Опыт: не нужен. Как мы работаем: 1. Ты проходишь обучение пару недель; 2. Берёшь реальный проект из моей базы; 3. Собираешь бота по проверенной формуле; 4. Наставник контролирует процесс; 5. Получаешь деньги и закрепляешь клиента. Весь процесс занимает до 2х недель с нуля до первых денег на твою карту. Даниил из Балашихи был военнослужащим — с июля 2024 года начал создавать чат-ботов для бизнеса и уже заработал 4 млн. рублей. А главное теперь у него больше свободного времени на семью, друзей и развлечения. Да, ты не первый. 103 человека уже ведут постоянных клиентов по моей формуле. Ведь сайт со статистикой Wordstat показывает 10 786 запросов за месяц в поисковике от бизнеса на эту услугу. Заказов валом. Срочно нужны твои руки и голова. Чтобы быстро разобраться во всех нюансах — запускай бота Там пошаговый план как стартануть и гайд по клиентам. 8 мест ещё свободно

Как корректно сравнивать значения с NULL? Обычное сравнение может сломаться, когда в данных появляется NULL. В SQL выражение:

email <> 'admin@example.com'

не вернёт строки с email IS NULL — результат будет UNKNOWN. Для корректного сравнения используйте IS DISTINCT FROM:

email IS DISTINCT FROM 'admin@example.com'

Оно работает так, как ожидаешь: NULL ≠ любое значение NULL = NULL Результат всегда TRUE или FALSE (без UNKNOWN). То же самое для проверки изменений:

old_value IS DISTINCT FROM new_value

🔥 Это инструмент не для синтаксиса, а для корректности данных. ➡️ SQL Ready | #совет

DISTINCT vs GROUP BY — выбираем правильный инструмент для удаления дублей! В SQL часто нужно избавиться от повторяющихся строк: уникальные пользователи, товары, категории. Для этого используют DISTINCT и GROUP BY. Результат может выглядеть одинаково, но назначение и смысл у этих конструкций разные. Представим таблицу заказов:

orders(id, customer_id, product_id)

Найдём всех уникальных клиентов, которые делали заказы:

SELECT DISTINCT customer_id
FROM orders;

DISTINCT удаляет дубликаты по всему набору выбранных колонок в результирующем наборе — без группировок и агрегаций. Сделаем то же самое через GROUP BY:

SELECT customer_id
FROM orders
GROUP BY customer_id;

Результат будет тем же, но семантически запрос другой: явно группируем строки по customer_id. В простых случаях оптимизатор часто строит одинаковый план, но логика запроса уже «про группы». GROUP BY становится необходимым, когда появляются агрегаты. Посчитаем количество заказов на каждого клиента:

SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id;

В этом запросе GROUP BY обязателен, потому что мы одновременно выбираем агрегат (COUNT(*)) и неагрегированное поле (customer_id). Частая ошибка — смешивать DISTINCT и агрегаты без GROUP BY:

SELECT DISTINCT customer_id, COUNT(*)
FROM orders;

Такой запрос в стандартном SQL некорректен: неагрегированные поля должны присутствовать в GROUP BY. В зависимости от СУБД и режима он либо не выполнится, либо вернёт неопределённый результат. Корректный вариант:

SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id;

🔥 Используй DISTINCT для простого удаления дублей, а GROUP BY — когда нужна агрегация, расчёты по группам или HAVING. ➡️ SQL Ready | #практика

👩‍💻 В сеть вывалилась гигантская куча курсов и книг от топовых IT‑школ Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё! • 1612 ГБ — DevOps • 1402 ГБ — Python • 1300 ГБ — C, C++ • 1815 ГБ — Frontend • 1515 ГБ — Backend • 898 ГБ — ИБ, Хакинг • 996 ГБ — Kotlin, Swift • 212 ГБ — JavaScript • 315 ГБ — Flutter • 820 ГБ — Go, PHP • 419 ГБ — Java, Rust • 648 ГБ — GameDev • 517 ГБ — Windows, Linux • 998 ГБ — Дизайн (UX/UI) • 617 ГБ — Нейросети (ML/RL) • 546 ГБ — БД (SQL & NoSQL) • 687 ГБ — Аналитика данных • 115 ГБ — QA-тестирование Подписывайся и не плати за то, что можно получить бесплатно

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

Как избежать блокировок таблиц с помощью advisory locks в PostgreSQL! Иногда нужно гарантировать, что только один процесс выполняет критическую секцию, но при этом не хочется блокировать таблицы и строки. Для этого PostgreSQL предоставляет advisory locks — логические блокировки, не привязанные к таблицам или строкам.

SELECT pg_advisory_xact_lock(42);

Пока транзакция активна, другие процессы с тем же ключом будут ожидать. Ключ — это просто число. Можно использовать user_id, order_id, хеш или tenant_id.

SELECT pg_advisory_xact_lock(user_id);

🔥 Это превращает PostgreSQL в механизм распределённой синхронизации. После COMMIT или ROLLBACK блокировка снимается автоматически. ➡️ SQL Ready | #совет

Префиксные индексы в MySQL — ускоряем поиск по длинным строкам! Полные индексы на длинных строках занимают много ресурсов, тогда как префиксные индексируют только первые N символов, уменьшая объём индекса и ускоряя поиск при высокой селективности начала строки. Создадим таблицу с длинным текстовым атрибутом — типичный кейс, где полный индекс был бы слишком тяжёлым:

CREATE TABLE documents (
    id INT PRIMARY KEY,
    doc_key VARCHAR(500) NOT NULL
);

Добавим префиксный индекс. Индексируются только первые 20 символов:

CREATE INDEX idx_doc_key_prefix
ON documents (doc_key(20));

Если фильтровать данные по фиксированному началу строки, MySQL использует префиксный индекс:

SELECT id
FROM documents
WHERE doc_key LIKE 'INV-2024-%';

Важно: индекс применяется только если шаблон начинается без ведущего %. Например, LIKE '%2024%' уже не сможет его использовать. Пример с email — если полная индексация не нужна:

CREATE INDEX idx_email_prefix
ON users (email(16));

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