SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
Ko'proq ko'rsatish📈 Telegram kanali SQL Ready | Базы Данных analitikasi
SQL Ready | Базы Данных (@sql_ready) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 17 754 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 7 324-o'rinni va Rossiya mintaqasida 37 073-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 17 754 obunachiga ega bo‘ldi.
19 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 712 ga, so‘nggi 24 soatda esa 32 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 12.57% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 5.99% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 230 marta ko‘riladi; birinchi sutkada odatda 1 062 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 23 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent sql, строка, users, индекс, user_id kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 20 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
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 | #совет