SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
Show more📈 Analytical overview of Telegram channel SQL Ready | Базы Данных
Channel SQL Ready | Базы Данных (@sql_ready) in the Russian language segment is an active participant. Currently, the community unites 17 754 subscribers, ranking 7 324 in the Technologies & Applications category and 37 073 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 17 754 subscribers.
According to the latest data from 19 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 712 over the last 30 days and by 32 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 12.57%. Within the first 24 hours after publication, content typically collects 5.99% reactions from the total number of subscribers.
- Post reach: On average, each post receives 2 230 views. Within the first day, a publication typically gains 1 062 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 23.
- Thematic interests: Content is focused on key topics such as sql, строка, users, индекс, user_id.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
Thanks to the high frequency of updates (latest data received on 20 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
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 Ready | #задача
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 Ready | #шпора• Храним шаблоны фраз и ответы в таблице responses; • Используем ILIKE, чтобы находить ключевые слова в сообщении; • Возвращаем лучший ответ по приоритету совпадений.Приём показывает, что SQL способен работать не только с числами, но и с текстом, превращаясь в мини-экспертную систему. ➡️ SQL Ready | #задача
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 помогает сократить код и избежать дублирования столбцов.
Объединим заказы и клиентов по общему полю:
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 | #практикаВ этой шпаргалке собраны основные оконные функции Oracle SQL, применяемые для аналитики, ранжирования и работы с порядком строк без свёртки данных. Они вычисляют значения в контексте "окна" — набора строк, связанных с текущей строкой. Это мощный инструмент для аналитических отчётов и сложных выборок.
➡️ SQL Ready | #шпораINCLUDE решает это: добавляет нужные колонки в индекс и превращает Index Scan в Index Only Scan.
Сегодня в посте:
• Как работает INCLUDE и почему это не дублирование; • Как проверить, что запрос действительно читает только индекс; • Где Covering Index даёт реальный прирост.Производительность начинается не с кода, а с структуры индекса. ➡️ SQL Ready | #гайд
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 Ready | #задача
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 | #совет• Как создать таблицу с RANGE-партициями; • Почему фильтры по ключу в разы ускоряют SELECT; • Как безопасно удалять старые данные за миллисекунды.Это инструмент архитектуры, а не оптимизации, если он внедрён правильно таблица работает быстро. ➡️ SQL Ready | #гайд
