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

🖥 Partitioning — фундамент для больших таблиц! Партиционирование позволяет разбить данные по логике (дата, регион, тип) и ускорить работу без сложных трюков. Сегодня в посте:

• Как создать таблицу с RANGE-партициями; • Почему фильтры по ключу в разы ускоряют SELECT; • Как безопасно удалять старые данные за миллисекунды.

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

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

RANK vs DENSE_RANK: точное ранжирование в SQL! При создании рейтингов или аналитических сводок часто нужно определить позиции записей по показателю — с учётом повторов. Для этого используются оконные функции RANK() и DENSE_RANK(). Создадим таблицу с продажами:

CREATE TABLE sales (
  employee TEXT,
  total_sales INT
);

INSERT INTO sales VALUES
('Alice', 500),
('Bob', 700),
('Charlie', 700),
('Diana', 400);

Выполним ранжирование по сумме продаж:

SELECT employee,
       total_sales,
       RANK() OVER (ORDER BY total_sales DESC) AS rank_pos,
       DENSE_RANK() OVER (ORDER BY total_sales DESC) AS dense_rank_pos
FROM sales;

Результат:

employee | total_sales | rank_pos | dense_rank_pos
---------+--------------+----------+----------------
Bob      | 700          | 1        | 1
Charlie  | 700          | 1        | 1
Alice    | 500          | 3        | 2
Diana    | 400          | 4        | 3

🔥 Так что, RANK() пропускает позиции после повторов, а DENSE_RANK() идёт подряд, без «дыр» в нумерации. ➡️ SQL Ready | #практика

В Яндексе платят 300.000р, Сбер нуждается в инженерах, а в Тинькофф нехватка кадров «Бигтех по-русски» — место, где разработчики из крупных компаний рассказывают правду о работе мечты, зарплатах и жизни в IT. Присоединяйся: @bigtech