SQL Ready | Базы Данных

Ir al canal en Telegram

Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready

Rusia43 154 Tecnologías y Aplicaciones8 396...

📈 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 15 552 suscriptores, ocupando la posición 8 396 en la categoría Tecnologías y Aplicaciones y el puesto 43 154 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 15 552 suscriptores.

Según los últimos datos del 11 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de 56, y en las últimas 24 horas de -9, 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.41%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 6.30% de reacciones respecto al total de suscriptores.
Alcance de las publicaciones: Cada publicación recibe en promedio 1 931 visualizaciones. En el primer día suele acumular 980 visualizaciones.
Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 24.
Intereses temáticos: El contenido se centra en temas clave como sql, строка, user_id, created_at, desc.

📝 Descripción y política de contenido

El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready”

Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 12 junio, 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.

15 552

Suscriptores

-924 horas

+307 días

+5630 días

1 931

Visitas de la publicación

~ 98024 horas

~ 1 15048 horas

12.41%

Tasa de compromiso

~ 1

Mensajes por día

Ads index

beta

Archivo de publicaciones

15 552

☕️ Смотрите что нашел — Explainshell. Вводишь любую команду в терминале, и он по частям объясняет, что делает каждая часть. Не просто man-ка, а понятный синтакс-анализ. Особенно кайф для тех, кто работает в Linux/DevOps/CI среде и хочет разбираться, а не наугад копипастить из StackOverflow. 📌 Оставляю ссылочку: explainshell.com ➡️ SQL Ready | #ресурс

15 552

EXPLAIN — узнаём, как СУБД реально выполняет ваш запрос! Команда EXPLAIN показывает, что делает база данных под капотом при выполнении SQL-запроса. Это помогает найти узкие места и понять, почему запрос может работать медленно. Допустим, у нас есть запрос:

SELECT * FROM books WHERE author = 'Толстой';

Запускаем EXPLAIN, чтобы посмотреть план выполнения:

EXPLAIN SELECT * FROM books WHERE author = 'Толстой';

Если видим Table Scan или Seq Scan — это означает, что происходит полный просмотр таблицы. Такой способ может быть медленным, особенно при большом объёме данных. Чтобы ускорить выполнение, создаём индекс:

CREATE INDEX idx_author ON books(author);

🔥 Теперь при повторном EXPLAIN запрос может использовать Index Scan, что значительно быстрее. ➡️ SQL Ready | #практика

15 552

{… устанавливаю личность…}

⌛️ loading . . .

{…сканирую слитые базы…}

доступ ✅ разрешён

🎥 системы распознавания лиц 👁️ базы правоохранителей 📁 утилиты для взлома слежки ↑ ↓

Добро пожаловать на самый продвинутый ресурс по кибербезопасности и хакингу

C O N И E C T ⇢ @TechLab

15 552

📂 Напоминалка по нормальным формам баз данных! Например, 1NF требует атомарных значений, 2NF убирает частичные зависимости, а 3NF избавляет от транзитивных зависимостей. На картинке — основные нормальные формы, которые полезны при проектировании SQL-баз данных. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

15 552

Согласованное чтение данных внутри одной транзакции! Иногда несколько SELECT должны работать с одной и той же версией данных, даже если параллельно идут изменения.

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;

В PostgreSQL это фиксирует MVCC snapshot в момент первого statement внутри транзакции:

SELECT COUNT(*) FROM orders;

Все последующие SELECT читают один и тот же snapshot и не видят новые COMMIT из других сессий, при этом собственные изменения транзакции видны:

SELECT SUM(amount) FROM orders;

Это гарантирует согласованность результатов между запросами без блокировки пишущих транзакций:

COMMIT;

🔥 После COMMIT snapshot освобождается, транзакция завершается. ➡️ SQL Ready | #совет

15 552

SQL отработал, но цифры не сходятся? SQL Логи бизнеса — канал про реальные рабочие задачи аналитика Здесь: 🔸ловушки с собеседований 🔸разборы запросов, которые «работают, но не так как надо» 🔸кейсы из банковской аналитики 🔸тесты Канал ведёт действующий банковский аналитик с опытом работы в Сбере и Т-Банке и с дипломом ВШЭ Если вам нужен SQL для работы и собеседований — добро пожаловать в SQL Логи бизнеса Вот некоторые посты с канала: • Самая частая ошибка джунов • Когда запрос работает, но выдает не то, что вы ожидаете • Когда действительно нужен self-join

15 552

Оконные фреймы (ROWS и RANGE) — управление областью расчёта! В оконных функциях важны не только PARTITION BY и ORDER BY, но и то, какие строки попадают в окно вычисления. За это отвечают оконные фреймы — ROWS и RANGE. Таблица операций:

transactions(id, user_id, amount, created_at)

Накопительная сумма по пользователю:

SUM(amount) OVER (
  PARTITION BY user_id
  ORDER BY created_at
)

При наличии ORDER BY и отсутствии явного фрейма в большинстве СУБД используется RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. Если значения created_at совпадают, сумма считается сразу по группе строк (peers). Среднее по последним 3 операциям:

AVG(amount) OVER (
  PARTITION BY user_id
  ORDER BY created_at, id
  ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
)

ROWS формирует окно по количеству строк. Детерминированный ORDER BY необходим для воспроизводимого результата. Сумма за последние 7 дней (пример для PostgreSQL):

SUM(amount) OVER (
  PARTITION BY user_id
  ORDER BY created_at
  RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW
)

RANGE формирует окно по значениям ORDER BY. Поддержка и синтаксис интервалов зависят от СУБД; часто допускается только одно выражение в ORDER BY. 🔥 Важно помнить: ROWS — предсказуем по количеству строк, RANGE — удобен для временных интервалов и peer-групп, неявный фрейм может менять результат вычислений ➡️ SQL Ready | #практика

15 552

Появился мощный инструмент для прохождения собеседований — Sobes Copilot. Это нейросеть, которая подсказывает ответы прямо во время интервью, анализируя разговор в реальном времени. Copilot работает незаметно в Zoom, Google Meet, Teams и других платформах. Поддерживает русский язык, не виден при демонстрации экрана и помогает держать уверенный темп диалога, даже если вопрос сложный или неожиданный. Дополнительно Sobes Copilot делает пост-анализ собеседования: разбирает диалог после созвона, подсвечивает сильные и слабые моменты, удачные формулировки и зоны роста. Это позволяет понять, что сработало, а что стоит улучшить перед следующим интервью. Если хотите проходить собесы спокойнее и увереннее — изучите возможности сервиса по ссылке. Это действительно меняет игру. 🎁 Промокод: SOBES26 — даёт 10% скидки на старт.

15 552

💡 ThoughtSpot SQL Tutorial — продуктивное обучение и практика! Материал построен вокруг реальных примеров и практики: от базовых SELECT, JOIN и агрегатов до сложных подзапросов и аналитических функций. Пояснения идут шаг за шагом, с визуальными примерами и задачами, которые помогают сразу закрепить навыки на практике. 📌 Оставляю ссылочку: thoughtspot.com ➡️ SQL Ready | #ресурс

15 552

Как выполнять сложные data-миграции, не ломая UNIQUE-ограничения? Иногда нужно массово менять данные, временно нарушая UNIQUE, но итоговое состояние корректно:

BEGIN;

Включаем отложенную проверку конкретного ограничения, оно проверится только при COMMIT:

SET CONSTRAINTS users_email_uniq DEFERRED;

Теперь можно выполнять UPDATE/INSERT, даже если в процессе появляются дубликаты:

UPDATE users
SET email = lower(email);

Фиксация происходит один раз, если финальное состояние валидно, транзакция коммитится:

COMMIT;

Если уникальность нарушена в конце будет ROLLBACK, без частичных изменений. 🔥 Отложенные ограничения позволяют безопасно менять данные внутри транзакции, сохраняя целостность и контроль без временного снятия UNIQUE. ➡️ SQL Ready | #совет

15 552

Программисты, это вам 👇 Держите 5 каналов, которые реально помогают изучать программирование и IT с полного нуля: 🖥 Easy Coder — все направления IT. 👩‍💻 Easy Python — всё о Python. 🌐 Easy WebDev — Frontend, Backend. 🔠 Easy InfoSec — ИБ, Хакинг. 🖥 Easy GitHub — лучшее с GitHub. Тонны бесплатной инфы для любого уровня подготовки ✔️

15 552

☕️ Наткнулся на любопытную статью — «Embedded SQL с группировкой запросов: элегантный подход к управлению SQL в Go»! В этой статье:

• Автор показывает, как хранить и группировать SQL-запросы в одном .sql-файле по сущностям;
• Рассказывается, как использовать go:embed для встраивания этих файлов в бинарник и загружать запросы по имени;
• Представлен парсер, который разбирает .sql с именованными секциями;
• Показаны преимущества подхода: подсветка SQL в IDE, чистый Go-код и др.

🔊 Продолжайте читать на Habr!

➡️ SQL Ready | #статья

15 552

UNION и UNION ALL — когда строки исчезают без ошибок! UNION удаляет дубликаты по всем выбранным колонкам, сравнивая строки целиком, поэтому результат может отличаться от ожиданий.

SELECT message FROM logs_app
UNION
SELECT message FROM logs_system;

Одинаковые message схлопнутся в одну строку, даже если это разные события — ошибки не будет. UNION ALL не удаляет строки из результата запросов, поэтому почти всегда работает быстрее:

SELECT message FROM logs_app
UNION ALL
SELECT message FROM logs_system;

Для логов полезно явно добавлять источник:

SELECT 'app' AS src, id, message FROM logs_app
UNION ALL
SELECT 'system' AS src, id, message FROM logs_system
ORDER BY src, id;

Пересечение (INTERSECT) в MySQL не поддерживается, альтернатива:

SELECT DISTINCT a.message
FROM logs_app a
WHERE EXISTS (SELECT 1 FROM logs_system s WHERE s.message = a.message)
LIMIT 10;

Если хотите увидеть, какие строки пропадут при UNION из-за совпадений между таблицами, используйте UNION ALL и проверяйте строки, встречающиеся в обоих источниках:

SELECT message, COUNT(*) AS cnt, COUNT(DISTINCT src) AS sources
FROM (
    SELECT message, 'app' AS src FROM logs_app
    UNION ALL
    SELECT message, 'system' AS src FROM logs_system
) t
GROUP BY message
HAVING sources > 1;

🔥 UNION — когда нужна дедупликация, UNION ALL — когда важна каждая строка и производительность. ➡️ SQL Ready | #практика

15 552

Все надоело и пропал интерес, чувствуешь себя амебой и хочется только залипать в телефоне. Бывает? Homo Manifestans — канал для айтишников, у которых периодически опускаются руки и отключается мозг, ибо переработки и постоянная тревожность не приводят к другим исходам 🤗 ✓ Как научиться отвлекаться от работы и отдыхать? ✓ Как совместить кучу рабочих задач и время с семьей? ✓ Как справиться с прокрастинацией? ✓ Как не растерять запал, даже если начальник и коллеги 💩 и кажется, что ничего не выходит? Подписывайтесь на канал @vadimpetrovpsi и научитесь работать без упахивания, выгорания и ущерба для личной жизни! Псс. Заходите в закреп — там много полезного, и даже бесплатный мини-курс по выходу из апатии: 👉 https://t.me/+K9SYzZ0KYe04YTMy

15 552

📂 Напоминалка по структурам баз данных! Например, Skiplist ускоряет поиск в памяти, Hash-индекс даёт доступ за O(1), а B-tree и LSM-дерево оптимизируют работу с диском и записью. На картинке — 8 структур данных, которые стоит держать под рукой, чтобы понимать, как устроены индексы и хранение в БД. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

15 552

Сравнение наборов и вычисление пересечения по ключу! Нужно быстро получить пересечение двух таблиц по ключу? Используйте JOIN по колонке, которая логически должна совпадать в обоих наборах:

JOIN table_b b ON a.id = b.id

Выберите только ключи, чтобы исключить лишние проекции и ускорить анализ наборов:

SELECT a.id

Проверьте сами на интерактивном примере:

CREATE TABLE table_a(id int);
CREATE TABLE table_b(id int);
INSERT INTO table_a VALUES (1),(2),(3);
INSERT INTO table_b VALUES (2),(3),(4);

Повторите исходный JOIN, вы увидите только 2,3 как пересечение наборов. 🔥 Пригодится, когда нужно сверить итерации, найти общие сущности перед миграциями и тд. ➡️ SQL Ready | #совет

15 552

🤩ChatGPT - Мёртв💀 Для разных задач все давно используют разные нейросети, а OnlyAI рассказывает об этом ВСЁ Самые залайканые посты OnlyAi 🔽🔽🔽

Получаем платную версию:🤩🤩🤩🤩🤩🤩🔐

Оживляем фото, генерим студийную фотосессию с собой 💪

Делаем из нейронки флирт бота влюбляем в себя любую ❤️

Зарабатываем на крипте с помощью прогнозов нейронки 💸

Снимаем цензуру одним промтом🤬

Как сделать из нейронки помощника или друга ✍️

Решаем любую домашку одной фоткой 📸

15 552

❤️ SQL-EX — интерактивный тренажёр с задачами! Если хочешь учиться через практику, этот сайт отличный инструмент. Здесь ты пишешь запросы прямо в браузере, получаешь мгновенную обратную связь и видишь результат. Подойдёт для закрепления теории, подготовки к собеседованию или реальных задач в работе с бд. 📌 Оставляю ссылочку: sql-ex.ru ➡️ SQL Ready | #ресурс

15 552

Find + Update в одном проходе! Найдём строки с невозможными значениями и сразу подготовим их к UPDATE:

WITH c AS (SELECT id FROM products WHERE price < 0 LIMIT 3)

CTE c вернёт проблемные id. Теперь обновим только найденные строки, не дублируя условие в клиенте:

UPDATE products SET price = 0

Ссылаемся на выборку из CTE, чтобы не рассинхронизировать find/update:

WHERE id IN (SELECT id FROM c);

Попробуйте сами на тестовой таблице:

CREATE TABLE products(id int PRIMARY KEY, price int);
INSERT INTO products VALUES (1,-10),(2,-5),(3,100);

Запустите find+update снова и убедитесь, что исправление точечное и атомарное. 🔥 Экономит время выравнивания таблиц при интеграциях, корректировки классификаторов или миграций и др. ➡️ SQL Ready | #совет

15 552

⚡️ Тимлид из Сбера спалился на использовании ChatGPT Причём схема работала целый год: задачи всей команды сбрасывали в нейронку, используя особые промты. Тимлида уволили, и в порыве гнева он создал блог НейроПульс, где сливает все лайфхаки работы с ИИ: – Как получить безлимитные генерации – Промты, улучшающие ответы ChatGPT в 10 раз – Дикие способы заработка на ИИ Сохраняй, пока чувака не заблокировали техно-гиганты: https://t.me/+rzu4ballvikwZmNi