SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
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 15 549 subscribers, ranking 8 397 in the Technologies & Applications category and 43 185 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 15 549 subscribers.
According to the latest data from 12 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 53 over the last 30 days and by -8 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 11.96%. Within the first 24 hours after publication, content typically collects 6.22% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 860 views. Within the first day, a publication typically gains 967 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, строка, user_id, created_at, desc.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_it
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
Thanks to the high frequency of updates (latest data received on 13 June, 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.
В этой шпаргалке собраны основные оконные функции 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 | #гайд
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 | #практика• Генерируем данные через GENERATE_SERIES() и RANDOM(); • Проверяем, сколько попыток оказались успешными; • Анализируем распределение “удачных” чисел по всем догадкам.Игра помогает тестировать генераторы случайных значений, проверять равномерность распределений и моделировать тесты. ➡️ SQL Ready | #задача
✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером. ✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.Почему стоит участвовать: 🔘Кейс в портфолио и полезная обратная связь от менторов Т1 🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний 🔘Реальный опыт командной работы 🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси. Регистрация открыта! ➡️ Успей до 23 ноября по ссылке. Реклама. ООО "ГК "Иннотех" ИНН 9703073496 ERID 2VtzqxXvjVG
Covering Index — это индекс, который уже содержит все данные, нужные запросу.
Если запрос обращается только к колонкам, включённым в индекс — таблица может не читаться вовсе:
CREATE INDEX idx_orders_status_user
ON orders (status, user_id);
Теперь запрос:
SELECT user_id, status
FROM orders
WHERE status = 'pending';
Выполняется полностью из индекса — минимум I/O, максимум скорости.
В PostgreSQL это видно как Index Only Scan в плане:
EXPLAIN ANALYZE SELECT ...
Работает только если строки помечены all-visible (visibility map). В MySQL аналог — Using index, в SQL Server — INCLUDE в индексе.
🔥 Не забывайте: больше индексов = больше места и медленнее вставки/обновления.
➡️ SQL Ready | #советВ этой шпаргалке — функции PostGIS для пространственного анализа: вычисление расстояний и площадей, определение пересечений и вложенности геометрий, создание буферов и экспорт в GeoJSON. Эти инструменты полноценной ГИС-платформой для хранения, обработки и анализа геоданных.
➡️ SQL Ready | #шпора
Available now! Telegram Research 2025 — the year's key insights 
