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

Open in Telegram

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

Russia43 154 Technologies & Applications8 396...

📈 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 559 subscribers, ranking 8 396 in the Technologies & Applications category and 43 154 in the Russia region.

📊 Audience metrics and dynamics

Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 15 559 subscribers.

According to the latest data from 11 June, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 56 over the last 30 days and by -9 over the last 24 hours, overall reach remains high.

Verification status: Not verified
Engagement rate (ER): The average audience engagement rate is 12.41%. Within the first 24 hours after publication, content typically collects 6.30% reactions from the total number of subscribers.
Post reach: On average, each post receives 1 931 views. Within the first day, a publication typically gains 980 views.
Reactions and interaction: The audience actively supports content: the average number of reactions per post is 24.
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 12 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.

15 559

Subscribers

-924 hours

+307 days

+5630 days

1 931

Post views

~ 98024 hours

~ 1 15048 hours

12.41%

Engagement rate

~ 1

Posts per day

Ads index

beta

Posts Archive

15 559

"Как стать независимыми от зарубежных систем управления базами данных (СУБД)?" Этот вопрос сегодня остро стоит не только перед банками и финтех-компаниями, но и перед промышленными, торговыми, сервисными и государственными организациями. 💡Если такие вопросы возникают и у вас, приглашаем на вебинар от Диасофт и Ассоциации ФинТех (АФТ) на тему "Digital Q.DataBase: современный путь перехода с MS SQL Server и Oracle". 10 марта в 12:00 эксперты расскажут, как Digital Q.DataBase помогает перенести промышленные решения с MS SQL Server и Oracle, сохранив привычную логику и SQL-код. Они также представят новые возможности СУБД и расскажут практический кейс (историю успеха!) 🚀 💌Принимайте приглашение и регистрируйтесь по ссылке! #реклама О рекламодателе

15 559

❤️ Stepik SQL — практический курс с примерами запросов и упражнениями! Этот репозиторий содержит структурированные задания, схемы баз данных и примеры SQL-запросов из курса на Stepik. Материалы охватывают работу с таблицами, фильтрацию, JOIN, группировки, агрегаты и другие ключевые темы языка, с акцентом на практику. Отличный ресурс для тех, кто хочет закрепить теорию через задачи.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

15 559

Анти-JOIN — как корректно выбирать строки без связанных записей! Частая задача в SQL — найти строки, для которых отсутствуют связанные записи в другой таблице. Это классический anti-join. Например, нужно получить клиентов, которые ни разу не сделали заказ. Таблицы:

customers(id, name)
orders(id, customer_id, created_at)

LEFT JOIN + IS NULL:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o  
  ON o.customer_id = c.id
WHERE o.id IS NULL;

LEFT JOIN возвращает всех клиентов. Если совпадений нет, поля из orders становятся NULL, и фильтр оставляет только клиентов без заказов. Проверять нужно гарантированно NOT NULL колонку правой таблицы (обычно PK, например o.id), иначе возможны логические ошибки. NOT EXISTS (предпочтительно):

SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
);

Запрос напрямую выражает отсутствие строк. В простом случае он эквивалентен LEFT JOIN, но лучше отражает намерение, устойчив к NULL в подзапросе и часто даёт более предсказуемый план при усложнении условий. Почему не NOT IN:

SELECT c.id, c.name
FROM customers c
WHERE c.id NOT IN (
    SELECT customer_id
    FROM orders
);

Если подзапрос возвращает хотя бы один NULL, результат может стать пустым из-за трёхзначной логики SQL. Использовать этот вариант безопасно только при гарантированном NOT NULL в orders.customer_id. Нюанс с условиями в JOIN:

SELECT c.id
FROM customers c
LEFT JOIN orders o  
  ON o.customer_id = c.id 
 AND o.created_at >= DATE '2026-01-01'
WHERE o.id IS NULL;

Этот запрос ищет клиентов без заказов после указанной даты. Если требуется найти клиентов вообще без заказов, добавлять условия в JOIN нельзя — это меняет бизнес-смысл. В таком случае корректнее использовать NOT EXISTS. 🔥 Минимально необходим индекс orders(customer_id). При частой фильтрации по дате логичен составной индекс (customer_id, created_at). ➡️ SQL Ready | #практика

15 559

👨👨👨👨👨👨👨👨👨👨 Каналы с IT мероприятиями Подписывайся, чтобы не пропустить 🤘 1. IT мероприятия для стажеров и студентов 2. IT мероприятия по РФ 3. IT мероприятия и хакатоны 4. Бесплатные IT мероприятия 5. IT мероприятия онлайн 6. IT мероприятия Москва 7. IT мероприятия Санкт-Петербург

15 559

📂 Напоминалка: как выполняется SQL-запрос в базе данных! Например, когда отправляешь SELECT, UPDATE или другой SQL, СУБД сначала обрабатывает его внутренне, а уже потом выполняет. На схеме — путь запроса: приём — разбор (парсер) — оптимизация — выполнение — доступ к данным — буферы, транзакции и блокировки — чтение/запись (память или диск). Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс

15 559

Что же выведет консоль?

Anonymous voting

15 559

15 559

❤️ Мега интересную статью нашёл на Хабре: «DOOMQL: DOOM-подобный многопользовательский шутер на чистом SQL»! В этой статье:

• Показано, как реализовать полноценную игру, от хранения состояния до рендеринга 3D-сцены — средствами одной лишь базы данных;
• Разобрана архитектура, игровой цикл на транзакциях и многопользовательская синхронизация через SQL;
• На реальном проекте демонстрируются неожиданные возможности СУБД далеко за пределами типичных CRUD-задач.

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

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

15 559

🖥 Oracle: работа с датой и временем!

Основные функции и приёмы работы с календарными значениями в Oracle: получение текущих даты и времени на стороне БД, вычисление интервалов, смещение по месяцам, усечение до нужной гранулярности, извлечение компонентов даты, а также корректное преобразование строк в DATE и TIMESTAMP. Полезно для отчётов, аналитики, планирования, ETL-процессов и любой логики, связанной с датами и временем.

➡️ SQL Ready | #шпора

15 559

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

15 559

Дедупликация с приоритетом, оставляем лучшую строку! Когда есть дубликаты по ключу (например, email), нужно сохранить запись с максимальным приоритетом — подтверждённую или самую новую. Таблица: users(id, email, is_verified, created_at) Сначала можно увидеть, какая строка будет считаться главной. Нумеруем строки внутри каждого email по приоритету:

SELECT id, email,
       ROW_NUMBER() OVER (
         PARTITION BY email
         ORDER BY is_verified DESC, created_at DESC
       ) rn
FROM users;

Оконная функция делит строки по email и присваивает номер согласно приоритету, где подтверждённые и более новые записи идут первыми. Оставим только одну запись на email — ту, у которой rn = 1:

SELECT *
FROM (
  SELECT *,
         ROW_NUMBER() OVER (
           PARTITION BY email
           ORDER BY is_verified DESC, created_at DESC
         ) rn
  FROM users
) t
WHERE rn = 1;

Все остальные строки в каждой группе автоматически становятся дублями. В PostgreSQL можно сделать то же самое короче:

SELECT DISTINCT ON (email)
       id, email, is_verified, created_at
FROM users
ORDER BY email, is_verified DESC, created_at DESC;

Здесь ORDER BY фактически задаёт правило выбора победителя внутри каждой группы. СУБД оставит одну строку на email согласно приоритету сортировки. 🔥 Такой приём используют при очистке импортов, объединении источников данных и выборе канонической записи пользователя. ➡️ SQL Ready | #практика

15 559

В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда? Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России 📆 в канале размещаются как онлайн, так и оффлайн мероприятия; 👩‍💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие; 🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах: 🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!

15 559

Проверка совпадений сразу по нескольким полям одной операцией! Когда нужно сравнить строки по составному ключу, многие пишут условия с AND, которые хуже читаются и сложнее поддерживаются:

u.email = b.email AND u.phone = b.phone

SQL умеет сравнивать кортежи целиком (row value), поэтому несколько колонок можно проверить одним выражением:

(email, phone)

Поддержка зависит от СУБД. Учитывайте поведение NULL и наличие составных индексов, оптимизация не всегда идентична AND. 🔥 Это особенно полезно при фильтрации, дедупликации, проверке попадания в списки, синхронизации таблиц и миграциях данных. ➡️ SQL Ready | #совет

15 559

SYSDATE в условиях — почему = SYSDATE почти никогда не то, что нужно! В Oracle SYSDATE возвращает текущие дату и время с точностью до секунды. Частая ошибка — пытаться выбрать записи «за сегодня» через прямое сравнение. Представим таблицу:

orders(id, created_at DATE)

Интуитивный вариант:

SELECT *
FROM orders
WHERE created_at = SYSDATE;

Логически кажется правильным — взять записи за текущий день. Но условие почти никогда не выполнится. Тип DATE в Oracle хранит и дату, и время (до секунды). Чтобы совпадение произошло, created_at должен быть ровно равен текущему моменту до секунды. На практике такой запрос почти всегда возвращает пустой результат. Попытка исправить через TRUNC:

SELECT *
FROM orders
WHERE TRUNC(created_at) = TRUNC(SYSDATE);

Работает корректно, но есть нюанс — функция применяется к колонке, поэтому обычный индекс по created_at не используется (если только нет function-based index на TRUNC(created_at)). Правильный способ — диапазон по дате:

SELECT *
FROM orders
WHERE created_at >= TRUNC(SYSDATE)
  AND created_at <  TRUNC(SYSDATE) + 1;

Такое условие индекс-дружелюбное (sargable), и оптимизатор может использовать индекс. Запрос выбирает все записи за текущие сутки независимо от времени (по часовому поясу сессии/сервера БД). Аналогично можно искать за любой день:

WHERE created_at >= DATE '2026-02-18'
  AND created_at <  DATE '2026-02-19'

Поскольку DATE хранит время, прямое равенство по дате почти никогда не подходит для выборки «за день». 🔥 Для выборки за день используйте полуоткрытый диапазон, а не сравнение с SYSDATE. ➡️ SQL Ready | #практика

15 559

👩‍💻 Хватит учить только синтаксис, начинай делать реальные проекты! Python Ready — авторский канал, где Python перестаёт быть только теорией и становится рабочим инструментом. Мини-проекты, боты, советы, разборы задач, гайды и шпаргалки для каждого программиста. 🔥 Советую подписаться: @python_ready

15 559

✍️ Bilabon — задачи и теория по MySQL! Это шпаргалка с ключевой теорией и упражнениями: управление БД и таблицами, типы данных, индексы, транзакции и оптимизация запросов. Также приведены практические задачи, позволяющие закрепить знания на примерах реальных предметных областей.

Оставляю ссылочку: GitHub 📱

➡️ SQL Ready | #репозиторий

15 559

🖥 Объединяем пересекающиеся интервалы автоматически! В реальных данных интервалы часто перекрываются или соприкасаются, из-за чего сложно понять фактические периоды непрерывной активности или занятости. Сегодня в задаче:

• Определим, насколько далеко тянется текущая занятость, отслеживая максимальный конец интервалов; • Найдём точки разрыва, где начинается новый независимый блок времени; • Объединим пересечения в итоговые непрерывные диапазоны.

Этот приём используют для анализа сессий, расписаний, бронирований и любых временных событий, где важно видеть реальные интервалы. ➡️ SQL Ready | #задача

15 559

Собрал чат-бота за вечер → заработал 9 000₽. Так и работают специалисты по чат-ботам: открыл шаблон → собрал бота как конструктор → получил деньги. Инструкция по сборке тут: 👉 @other_digital_bot

15 559

📂 Напоминалка по SQL — базовые команды и порядок выполнения запроса! Например, SELECT отвечает за выборку данных, FROM — за указание источника (таблицы), а WHERE позволяет отфильтровать строки по условию. На картинке — основные операторы SQL, типы JOIN’ов и правильный порядок выполнения запроса внутри СУБД. Сохрани, чтобы не забыть! ➡️ SQL Ready | #ресурс