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

Telegram опубликовал список 8 самых быстрорастущих каналов для программистов: Only Python — Подборки приёмов и фич, о которых не рассказывают в курсах. Only Tech — Главные тренды и инсайды из мира технологий, маркетинга и интернет-культуры. Only Hack — Реальные кейсы кибератак, инструменты и методы защиты, которые используют хакеры. Only GitHub — Репозитории, которые решают реальные задачи. Скрипты, фреймворки и готовые решения Only IT — Без мнений и слухов — только факты и важные IT-события. Only Apple — Новые апдейты, утечки и фишки, которые Apple ещё не показала. Only GPT — Промпты, хаки и свежие инструменты, о которых молчат даже AI-каналы. Only Memes — Если ты когда-нибудь деплоил в пятницу вечером — ты поймешь Подписывайтесь и прокачивайте свои скиллы.

Хочешь узнать, когда именно заказ сменил статус? Используй LAG(), она возвращает значение из предыдущей строки в рамках группы:

LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at)

Сравни текущее значение с предыдущим:

status <> LAG(status) OVER (...)

Получается булево поле — true, когда статус поменялся. Хочешь вывести только моменты изменения, просто оберни в подзапрос:

SELECT *
FROM (
  SELECT order_id, status, updated_at,
         status <> LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at) AS changed
  FROM order_status_log
) t
WHERE changed;

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

🖥 Корреляция: как связаны просмотры и продажи! SQL умеет не только суммировать и фильтровать данные, он способен показывать насколько сильно одно влияет на другое. В этом посте:

• Находим средние значения метрик; • Считаем ковариацию и дисперсии; • Собираем финальную формулу корреляции прямо в запросе.

Это помогает быстро проверять гипотезы, оценивать результаты и находить зависимости. ➡️ 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-тестирование Подписывайся и не плати за то, что можно получить бесплатно

WITHIN GROUP — агрегаты с управляемым порядком! Обычные агрегаты в SQL не гарантируют порядок входных данных, что важно для медиан и упорядоченных списков. Конструкция WITHIN GROUP решает это, задавая порядок элементов внутри агрегатной функции. Пример: соберём список продуктов по категории в порядке убывания продаж:

SELECT
    category_id,
    LISTAGG(product_name, ', ') WITHIN GROUP (ORDER BY total_sales DESC) AS top_products
FROM product_sales
GROUP BY category_id;

В отличие от ARRAY_AGG(product_name ORDER BY ...), синтаксис WITHIN GROUP используется для ordered-set функций, а не для любых агрегатов. Пример вычисления порогового значения 90% по сумме заказов по регионам:

SELECT
    region_id,
    PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY total_amount) AS p90_sales
FROM orders
GROUP BY region_id;

PERCENTILE_CONT() и PERCENTILE_DISC() позволяют вычислять медиану или любое процентное значение без оконных функций. Медиана чека по каждому магазину:

SELECT
    store_id,
    PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY total_amount) AS median_check
FROM orders
GROUP BY store_id;

Такой подход может быть проще и эффективнее, чем использование NTILE() или RANK() в оконных выражениях. 🔥 Используйте WITHIN GROUP, когда важен порядок в агрегатах. ➡️ SQL Ready | #практика

🖥 Временные таблицы и переменные в SQL Server! В этой шпаргалке собраны основные приёмы работы с временными данными в SQL Server: создание, заполнение, очистка и удаление временных таблиц, а также использование табличных переменных. Эти методы помогают выполнять промежуточные расчёты, строить отчёты и оптимизировать сложные запросы без изменения основной схемы базы. ➡️ SQL Ready | #шпора

🖥 Пишем мини-чат-бота! Сегодня создаём простого бота, который “понимает” текст запроса и отвечает на сообщения пользователя. В этом посте:

• Храним шаблоны фраз и ответы в таблице responses; • Используем ILIKE, чтобы находить ключевые слова в сообщении; • Возвращаем лучший ответ по приоритету совпадений.

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

Транзакция — не просто “begin и commit”, а ещё и способ управлять атомарностью и блокировками! Начинаешь с BEGIN — всё, что дальше, идёт как единое целое:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Если что-то падает, делай rollback, и база возвращается к исходному состоянию. Не забывай: каждая открытая транзакция держит блокировки. Чем дольше она живёт, тем выше шанс конфликтов. Контролируй уровень изоляции - баланс между скоростью и безопасностью:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

🔥 Производительность БД начинается с правильного управления транзакциями и блокировками. ➡️ SQL Ready | #совет

USING — способ объединять таблицы в SQL! Когда таблицы имеют одинаковые ключи, USING помогает сократить код и избежать дублирования столбцов. Объединим заказы и клиентов по общему полю:

SELECT *
FROM orders
JOIN customers USING (customer_id);

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

SELECT *
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id;

С USING SQL сам убирает дубликаты полей, оставляя одно customer_id в результирующем наборе. Можно соединять и по нескольким ключам:

SELECT *
FROM orders
JOIN shipments USING (order_id, customer_id);

Пример из аналитики: посчитаем сумму заказов по каждому клиенту:

SELECT customer_id,
       c.customer_name,
       SUM(o.amount) AS total_amount
FROM customers c
JOIN orders o USING (customer_id)
GROUP BY customer_id, c.customer_name
HAVING SUM(o.amount) > 1000
ORDER BY total_amount DESC;

🔥 Используйте USING, когда имена ключей совпадают — это приём, который улучшает читаемость и уменьшает вероятность ошибок. ➡️ SQL Ready | #практика

⚡️ Запускаем крупный розыгрыш призов, где можно выиграть iPhone 17, игровые наушники, клавиатуру и мышь! Без лишних слов, условия: 1. Подписка на: — бизнестрендс — Технотренды — Блумберг 2. Нажать кнопку «Участвовать» снизу Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!

❤️ CodeAbbey — тренажёр алгоритмического мышления! Сайт с огромной коллекцией задач по программированию, от самых простых до тех, что реально заставят подумать. Учиться можно на абсолютно любом языке. Отличный способ подтянуть логику, научиться писать аккуратный код и подготовиться к собесам. 📌 Оставляю ссылочку: codeabbey.com ➡️ SQL Ready | #ресурс

🖥 Аналитические (оконные) функции Oracle! В этой шпаргалке собраны основные оконные функции Oracle SQL, применяемые для аналитики, ранжирования и работы с порядком строк без свёртки данных. Они вычисляют значения в контексте "окна" — набора строк, связанных с текущей строкой. Это мощный инструмент для аналитических отчётов и сложных выборок. ➡️ 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 👨‍💻 Вакансии База обновляется еженедельно — всегда актуальные вопросы с последних собеседований, курсы и материалы. 📌 Подпишись, чтобы не потерять!

🖥 Covering Index — ускоряем запросы без изменения логики! Даже при наличии индекса SQL часто ходит в таблицу, чтобы добрать недостающие поля. INCLUDE решает это: добавляет нужные колонки в индекс и превращает Index Scan в Index Only Scan. Сегодня в посте:

• Как работает INCLUDE и почему это не дублирование; • Как проверить, что запрос действительно читает только индекс; • Где Covering Index даёт реальный прирост.

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

Миллионер-айтишник в 24 года? Знакомьтесь — это Влад, ему 24, и он программист без высшего образования.. IT и программирование — это ниша, которая никогда не умрет и в которой нет потолка ! ~ Думаешь это сложно? Я и тебя научу зарабатывать в IT и растить себя как высококлассного специалиста мирового уровня! Не веришь? Забирай бесплатные материалы в моем канале 👇 https://t.me/+y8aXUjB1nZAwZTI6

Выбираем уникальные записи с приоритетом по дате! Когда нужно взять по одной записи на пользователя, DISTINCT не всегда подходит: он не умеет выбирать, какая строка «главная». В PostgreSQL есть мощный приём — DISTINCT ON. Создадим таблицу:

CREATE TABLE users (
    id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    email TEXT NOT NULL,
    login_count INT,
    created_at TIMESTAMP DEFAULT now()
);

Добавим данные:

INSERT INTO users (email, login_count, created_at) VALUES
('alice@mail.com', 5, '2024-01-01'),
('alice@mail.com', 8, '2024-03-01'),
('bob@mail.com',   2, '2024-02-01');

Теперь выберем только последнюю запись на каждый email:

SELECT DISTINCT ON (email)
       email, login_count, created_at
FROM users
ORDER BY email, created_at DESC, id DESC;

Результат:

email           | login_count | created_at
----------------+--------------+----------
alice@mail.com  | 8            | 2024-03-01
bob@mail.com    | 2            | 2024-02-01

🔥 DISTINCT ON берёт по одной строке на группу, а ORDER BY задаёт, какая именно — последняя, первая или с нужным приоритетом. ➡️ SQL Ready | #практика

🖥 Симуляция “Живых клеток” Конвея! Сегодня создаём модель, в которой SQL решает судьбу каждой клетки — кто выживет, кто родится, а кто исчезнет. В этом посте:

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

Такой приём демонстрирует, что SQL может быть не только инструментом аналитики, но и полноценной средой моделирования. ➡️ SQL Ready | #задача

Если вы работаете в айти и не хотите вылететь с рынка через 3-4 года, развивайте софт-скиллы. Тимлиду не нужно уметь писать код – с этим лучше справляется его команда и даже нейронки, а вот грамотно менеджерить команду и выстраивать процессы – реально важный навык. Прокачивайте не только хард-скиллы, но и «гибкие» навыки — это то, что останется востребованным даже в эпоху ИИ. А если с головой нырять в обучение лень, читайте канал Тимлид на удалёнке. Там вся внутрянка от первого лица: как справляться с выгоранием, не терять фокус в условиях многозадачности и развить управленческие качества. С юмором, честно и без занудства. Почитайте на досуге, много нового узнаете: @teamleadonline

Ускоряй отчёты с материализованными представлениями! Когда отчёты считаются минутами, а данные почти не меняются, решение может быть в кэшировании результата. Используй материализованное представление (как VIEW, но результат хранится физически в таблице):

CREATE MATERIALIZED VIEW daily_stats AS
SELECT date(created_at) AS day,
       COUNT(*) AS total_orders
FROM orders
GROUP BY 1;

CREATE UNIQUE INDEX ON daily_stats(day);  -- нужно для CONCURRENTLY

Обновлять можно вручную или по расписанию (cron, pg_cron):

REFRESH MATERIALIZED VIEW_stats;

А если нужно без блокировок чтения:

REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats;

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