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 741 suscriptores, ocupando la posición 7 336 en la categoría Tecnologías y Aplicaciones y el puesto 37 136 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 741 suscriptores.
Según los últimos datos del 18 octubre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 696, y en las últimas 24 horas de 5, 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 6.05% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 2 222 visualizaciones. En el primer día suele acumular 1 069 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 19 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.
WHERE user_id NOT IN (SELECT id FROM users);
Если подзапрос вернёт хотя бы один NULL, условие станет UNKNOWN, и не вернётся ни одной строки.
Правильнее и безопаснее паттерн NOT EXISTS:
WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id);
Он корректно работает при NULL, не ломает логику и читается однозначно.
Хотите повторить? Проверьте разницу сами:
CREATE TABLE users(id int);
INSERT INTO users VALUES (1), (2), (NULL);
Теперь запустите:
SELECT 1 AS test WHERE 3 NOT IN (SELECT id FROM users);
Результат будет пустым.
🔥 А если переписать через NOT EXISTS, логика вернётся в норму.
➡️ SQL Ready | #советВ этой шпаргалке собраны ключевые функции и операторы PostgreSQL для создания, трансформации, агрегации и фильтрации массивов, а также проверки их пересечения и вхождения элементов. Материал охватывает приведение типов, разворачивание массивов в строки, сбор данных в массивы и использование операторов для логических проверок.
➡️ SQL Ready | #шпораVALUES как виртуальную таблицу, поэтому можно писать много строк прямо в INSERT:
INSERT INTO users (id, email, name) VALUES
(1, 'alice@mail.com', 'Alice'),
(2, 'bob@mail.com', 'Bob'),
(3, 'carol@mail.com', 'Carol');
Это работает мгновенно, просто читается и не создаёт лишних объектов в базе.
Хотите протестировать в своем проекте? Создайте таблицу и вставьте строки выше:
CREATE TABLE users (
id int PRIMARY KEY,
email text,
name text
);
🔥 Пригодится, когда нужно быстро заполнить таблицу для проверки логики.
➡️ SQL Ready | #советLoading … ██████████████] 99%Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.
ROW_NUMBER() присваивает уникальный порядковый номер строкам внутри логического окна. Данные не объединяются в группы, строки остаются как есть — это ключевое отличие от GROUP BY.
Таблица:
payments(id, user_id, amount, created_at)
Нумеруем платежи каждого пользователя. Окно создаётся по user_id, а нумерация идёт по дате от старых к новым:
SELECT id, user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at ASC) AS rn
FROM payments;
PARTITION BY разбивает данные на сегменты (в данном случае — по пользователю). ORDER BY внутри OVER() задаёт, в каком порядке будут присваиваться номера.
Чтобы найти последний платёж каждого пользователя, меняем порядок сортировки на DESC. Самая свежая запись получит номер 1 в своём окне:
WITH t AS (
SELECT id, user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM payments
)
SELECT * FROM t WHERE rn = 1;
Здесь используем CTE (WITH), чтобы сначала пронумеровать строки, а затем отфильтровать только нужный номер.
Следующий пример — логины пользователей:
auth_logs(id, user_id, ip, login_at)
Ищем первый вход каждого пользователя с каждого IP:
WITH t AS (
SELECT id, user_id, ip,
ROW_NUMBER() OVER (PARTITION BY user_id, ip ORDER BY login_at ASC) AS rn
FROM auth_logs
)
SELECT * FROM t WHERE rn = 1;
🔥 ROW_NUMBER() подходит, когда нужен номер строки в сегменте, важно выбрать первую/последнюю запись по логике сортировки,требуется топ-N по категориям или пользователям.
➡️ SQL Ready | #практика⏺️готовая база на сетевых или локальных дисках ⏺️постоянный primary endpoint ⏺️безопасное подключение через Private Link ⏺️автоматические бэкапы и обслуживания по твоему расписанию🎄🎁 И грант до 10 000 ₽ на запуск — чтобы точно не пришлось вспоминать, как настраивать failover вручную. ➡️Развернуть кластер
• Показан реальный подход к автоматическому развёртыванию PostgreSQL в закрытом контуре;
• Разбирается поддержка нескольких ОС, версий СУБД и схем отказоустойчивости;
• Описана автоматическая проверка соответствия требованиям архитектуры;
• Приведён практический кейс внедрения, рассчитанный на эксплуатацию в крупных корпоративных системах.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
SELECT relname,
last_analyze,
last_autoanalyze,
n_live_tup
FROM pg_stat_user_tables;
last_analyze — когда статистика обновлялась вручную,
last_autoanalyze — когда это делал autovacuum.
Чтобы быстро найти проблемные таблицы, отсортируем по размеру:
SELECT relname,
n_live_tup,
last_analyze,
last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;
Большая таблица + старый last_analyze — оптимизатор работает вслепую.
В таком случае достаточно обновить статистику:
ANALYZE;
Или точечно, для одной таблицы:
ANALYZE orders;
🔥 Это помогает объяснить внезапную деградацию запросов и понять, почему индекс игнорируется.
➡️ SQL Ready | #советOR 1=1 может вернуть все данные из таблицы, а blind SQLi позволяет вытаскивать информацию даже тогда, когда приложение не показывает ошибки и результаты запросов.
На картинке — основные типы SQL-инъекций, которые важно знать при работе с базами данных и backend-логикой.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс