SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
Mostrar más📈 Análisis del canal de Telegram SQL Ready | Базы Данных
El canal SQL Ready | Базы Данных (@sql_ready) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 17 754 suscriptores, ocupando la posición 7 324 en la categoría Tecnologías y Aplicaciones y el puesto 37 073 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 17 754 suscriptores.
Según los últimos datos del 19 octubre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 712, y en las últimas 24 horas de 32, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 12.57%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 5.99% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 230 visualizaciones. En el primer día suele acumular 1 062 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 23.
- Intereses temáticos: El contenido se centra en temas clave como sql, строка, users, индекс, user_id.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 20 octubre, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
SELECT *
FROM generate_series('2025-01-01', '2025-01-31', interval '1 day');
generate_series() создаёт виртуальную таблицу с шагом по дате.
Никаких временных таблиц, никаких циклов.
Теперь можно объединить это с данными:
SELECT g.day, COUNT(o.id) AS total
FROM generate_series('2025-01-01', '2025-01-31', interval '1 day') AS g(day)
LEFT JOIN orders o ON date(o.created_at) = g.day
GROUP BY g.day
ORDER BY g.day;
🔥 Пригодится для аналитики временных рядов,
заполнения пропусков и построения отчётов!
➡️ SQL Ready | #совет• Проверим, существует ли прямой путь, простой случай, но часто самый важный; • Расширим поиск и найдём маршруты вида A => X => B, где X — автоматически вычисленная пересадка; • Построим цепочки A => X => Y => B, что по сути является маленьким обходом графа.Это базовая техника работы с графами, подходит для поиска зависимостей, цепочек действий и любых последовательностей. ➡️ SQL Ready | #задача
WHERE, запросы тормозят. В PostgreSQL это решается GENERATED ALWAYS AS … STORED — выражение вычисляется один раз и хранится как обычное поле.
Создаём таблицу с материализованным выражением:
CREATE TABLE events (
id BIGSERIAL PRIMARY KEY,
payload JSONB NOT NULL,
event_type TEXT GENERATED ALWAYS AS (payload->>'type') STORED
);
Теперь event_type больше не вычисляется на лету — значение лежит прямо в строке.
Фильтрация становится проще и быстрее:
SELECT id
FROM events
WHERE event_type = 'purchase';
Добавляем индекс:
CREATE INDEX idx_events_event_type
ON events(event_type);
Проверяем:
EXPLAIN ANALYZE
SELECT id
FROM events
WHERE event_type = 'purchase';
🔥 Должен быть Index Scan, без тяжёлых операций над JSONB. Сгенерированные колонки отлично подходят для повторяющихся вычислений:
➡️ SQL Ready | #практикаSKIP LOCKED позволяет управлять конкурентным доступом на уровне строки, а не всей таблицы, поэтому воркеры не ждут друг друга и не создают лишних блокировок.
Сегодня в гайде:
• Забираем задачи параллельно и без конфликтов; • Делаем атомарный “взять + обновить” в одном запросе; • Распределяем очереди между воркерами под высокой нагрузкой.Этот прием делает обработку задач масштабируемой даже при высоком параллелизме. ➡️ SQL Ready | #гайд
Эта шпаргалка собирает основные псевдоколонки Oracle и показывает, как использовать их на практике: нумерация строк, доступ к физическому адресу, работа с иерархиями, определение листовых/корневых узлов, генерация UUID, отслеживание изменений по SCN и просмотр историй строк.
➡️ SQL Ready | #шпораa.start_at < b.end_at
AND b.start_at < a.end_at
Это условие покрывает все случаи перекрытий, даже частичных и вложенных.
Теперь объедини данные сами с собой:
SELECT a.id, b.id
FROM bookings a
JOIN bookings b
ON a.id < b.id
AND a.start_at < b.end_at
AND b.start_at < a.end_at;
a.id < b.id, чтобы не получить пары в обе стороны.
Хочешь анализировать бронирования по ресурсу? Добавь фильтр:
AND a.room_id = b.room_id
🔥 Теперь видно, какие заявки реально конфликтуют по времени.
➡️ SQL Ready | #советCROSS JOIN и простое условие.
В этом посте:
• Генерируем все пары чисел от 0 до 6; • Фильтруем зеркальные комбинации; • Получаем финальный набор костяшек в правильном порядке.Такой приём пригодится не только для домино — он полезен в задачах комбинаторики, генерации тестовых данных и построения матриц связей. ➡️ SQL Ready | #задача
FOR UPDATE.
Создаём таблицу с версией записи:
CREATE TABLE products (
id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name TEXT,
price DECIMAL(10,2),
version INT DEFAULT 1 NOT NULL
);
Выбираем запись для редактирования:
SELECT id, name, price, version
FROM products
WHERE id = 1;
Обновляем с проверкой версии:
UPDATE products
SET price = 199.99,
version = version + 1
WHERE id = 1
AND version = 1;
Если другой пользователь уже изменил эту строку, UPDATE не затронет ни одной записи — значит, версия изменилась, и данные устарели.
Приложение должно проверить, что rows_affected = 1, и при необходимости повторить попытку или показать сообщение об ошибке.
Проверяем результат:
SELECT * FROM products WHERE id = 1;
🔥 Такой подход предотвращает «потерю обновлений» без длительных блокировок чтения и подходит для большинства современных СУБД.
➡️ SQL Ready | #практика• Выявляем пропущенные минуты и события; • Находим дубликаты временных меток; • Контролируем качество потоков и ETL прямо в запросах.В продакшн-аналитике важно не только считать, но и замечать, где данные пропали или задублировались. ➡️ SQL Ready | #гайд
В этой шпаргалке собраны основные приёмы работы с JSON и JSONB в PostgreSQL: доступ к элементам, извлечение вложенных данных, обновление значений, создание объектов, раскрытие массивов, форматирование и проверка вхождения. Эти инструменты позволяют удобно хранить и обрабатывать структурированные данные прямо в базе.
➡️ SQL Ready | #шпора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 | #совет