SQL Ready | Базы Данных
Kanalga Telegram’da o‘tish
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_c РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready
Ko'proq ko'rsatish📈 Telegram kanali SQL Ready | Базы Данных analitikasi
SQL Ready | Базы Данных (@sql_ready) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 16 610 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 7 596-o'rinni va Rossiya mintaqasida 39 484-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 16 610 obunachiga ega bo‘ldi.
31 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 1 234 ga, so‘nggi 24 soatda esa 23 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 12.62% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 6.17% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 097 marta ko‘riladi; birinchi sutkada odatda 1 025 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
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Автор: @energy_c
РКН: https://clck.ru/3QREBc
Реклама на бирже: https://telega.in/c/sql_ready”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 01 Sentabr, 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.
16 610
Obunachilar
+2324 soatlar
+1547 kun
+1 23430 kun
Ma'lumot yuklanmoqda...
O'xshash kanallar
Ma'lumot yo'q
Muammo bormi? Iltimos, sahifani yangilang yoki bizning qo'llab-quvvatlash boshqaruvchimizga murojaat qiling>.
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Sentabr '26
Sentabr '260
1 kanalda
Avgust '26
+1 430
299 kanalda
Get PRO
Iyul '26
+121
37 kanalda
Get PRO
Iyun '26
+170
19 kanalda
Get PRO
May '26
+73
30 kanalda
Get PRO
Aprel '26
+138
31 kanalda
Get PRO
Mart '26
+315
66 kanalda
Get PRO
Fevral '26
+246
22 kanalda
Get PRO
Yanvar '26
+1 259
127 kanalda
Get PRO
Dekabr '25
+565
121 kanalda
Get PRO
Noyabr '25
+1 800
273 kanalda
Get PRO
Oktabr '25
+1 107
100 kanalda
Get PRO
Sentabr '25
+1 637
109 kanalda
Get PRO
Avgust '25
+1 628
240 kanalda
Get PRO
Iyul '25
+1 154
53 kanalda
Get PRO
Iyun '25
+1 368
87 kanalda
Get PRO
May '25
+2 597
331 kanalda
Get PRO
Aprel '25
+15
1 kanalda
Get PRO
Mart '25
+13
0 kanalda
Get PRO
Fevral '25
+28
0 kanalda
Get PRO
Yanvar '25
+26
1 kanalda
Get PRO
Dekabr '24
+18
1 kanalda
Get PRO
Noyabr '24
+73
5 kanalda
Get PRO
Oktabr '24
+2 310
253 kanalda
Get PRO
Sentabr '24
+2 772
270 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 01 Sentabr | 0 |
Kanal postlari
Почему коррелированные подзапросы могут снижать производительность SQL-запроса!
Коррелированные подзапросы удобны: внутри них можно обращаться к значениям текущей строки внешнего запроса.
Проблема в том, что оптимизатор может выбрать план, при котором такой подзапрос будет выполняться повторно для каждой строки внешней выборки. На больших объёмах данных это может стать узким местом. Например:
SELECT
u.id,
u.name,
(
SELECT SUM(o.amount)
FROM orders o
WHERE o.user_id = u.id
) AS total_amount
FROM users u;users содержит миллион строк, подзапрос потенциально может быть выполнен миллион раз. Даже при наличии индекса по orders.user_id такой подход иногда становится менее эффективным, особенно в сложных отчётах.
Часто можно сначала агрегировать данные, а затем присоединить результат:
SELECT
u.id,
u.name,
COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
SELECT
user_id,
SUM(amount) AS total_amount
FROM orders
GROUP BY user_id
) o
ON o.user_id = u.id;EXPLAIN / EXPLAIN ANALYZE.
Для получения последнего заказа пользователя часто используют оконные функции:
SELECT
user_id,
created_at
FROM (
SELECT
user_id,
created_at,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY created_at DESC
) AS rn
FROM orders
) t
WHERE rn = 1;(user_id, created_at DESC)SELECT ...
FROM orders
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 1;JOIN, предварительная агрегация или оконные функции позволяют значительно уменьшить количество лишних операций.
➡️ SQL Ready | #практика| 2 |  Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет
Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами.
И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную.
Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы.
Подписывайтесь, нас уже 60 тысяч: @vibecoding_tg | 818 |
| 3 |  📂 Шпаргалка по Backend-разработке!
Например, REST используется для построения API, Redis помогает кэшировать данные, а Docker позволяет упаковать приложение вместе со всеми его зависимостями.
На картинке — основные направления Backend-разработки: языки программирования, базы данных, API, авторизация, серверы, контейнеризация, CI/CD и мониторинг. Полезная карта того, что стоит изучить Backend-разработчику.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс | 1 057 |
| 4 |  Научите оптимизатор понимать ваши данные!
PostgreSQL по умолчанию считает, что значения в разных колонках независимы друг от друга. Но в реальных данных это часто не так.
Например, если city = 'Paris', то country почти всегда будет 'France'. Без этой информации оптимизатор может сильно ошибиться при оценке количества строк и выбрать неудачный план.
EXPLAIN
SELECT *
FROM users
WHERE country = 'France'
AND city = 'Paris';
Вместо того чтобы сразу создавать новый индекс, попробуйте расширенную статистику.
CREATE STATISTICS users_dep (dependencies)
ON country, city
FROM users;
ANALYZE users;
После ANALYZE PostgreSQL сможет учитывать зависимость между колонками и точнее оценивать селективность условий. Во многих случаях этого достаточно, чтобы оптимизатор выбрал более эффективный план выполнения.
🔥 Если запрос фильтрует по нескольким связанным колонкам и оптимизатор ошибается в оценке, сначала попробуйте CREATE STATISTICS, а уже потом решайте, нужен ли новый индекс.
➡️ SQL Ready | #совет | 1 155 |
| 5 |  🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку
Окружение решает больше, чем кажется.
Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре.
AI: t.me/ai_machinelearning_big_data
Python: t.me/pythonl
Linux: t.me/linuxacademiya
Хакинг: t.me/linuxkalii
ВАЙБКОДИНГ: t.me/data_analysis_ml
DevOps: t.me/DevOPSitsec
Docker: https://t.me/+90Z5TAyfuNU5YmRi
Golang: t.me/Golang_google
Rust: t.me/rust_code
C++: t.me/cpluspluc
C#: t.me/csharp_1001_notes
Java: t.me/javatg
JavaScript: t.me/javascriptv
React: t.me/react_tg
PHP: t.me/phpshka
Android: t.me/android_its
Мобильная разработка: t.me/mobdevelop
Базы данных: t.me/sqlhub
Big Data: t.me/bigdatai
Математика: t.me/data_math
Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy
Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy
Папка Frontend: https://t.me/addlist/mzMMG3RPZhY2M2Iy
ИТ-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy
Max Ai: https://max.ru/ai_machinelearning_big_data
Max python: https://max.ru/pythonl
ТЕХНО: https://max.ru/vistehno
Max Go: https://max.ru/Golang_google
Max Linux: https://max.ru/linuxkalii
Devops: https://max.ru/DevOPSitsec
C#: https://max.ru/csharp_ci
C++: https://max.ru/cpluspluc
SQL: https://max.ru/sqlhub
Java: https://max.ru/javatg
Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд. | 1 097 |
| 6 |  🤔 SQL Lab — интерактивная платформа для изучения и практики SQL!
Сайт для тех, кто хочет освоить SQL через работу с запросами. Код пишется прямо в браузере: выполняете запрос, сразу видите результат и получаете автоматическую проверку решения. Обучение построено от базовых SELECT и ORDER BY до JOIN, подзапросов, транзакций, индексов, оптимизации запросов и PostgreSQL. Есть структурированные курсы с теорией и практикой.
📌 Оставляю ссылочку: sqllab.ru
➡️ SQL Ready | #ресурс | 1 295 |
| 7 |  UNIQUE и NULL в PostgreSQL 15!
До PostgreSQL 15 уникальные ограничения считали NULL разными значениями. Это означало, что таблица спокойно принимала сколько угодно строк с NULL, даже если на колонке стоял UNIQUE.
CREATE TABLE users (
email text UNIQUE
);
INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);
Обе вставки выполнятся успешно.
Если NULL тоже должен быть уникальным, приходилось придумывать обходные пути. Кто-то делал частичные индексы, кто-то использовал COALESCE(), кто-то заводил отдельные флаги.
CREATE TABLE users (
email text,
CONSTRAINT users_email_key
UNIQUE NULLS NOT DISTINCT (email)
);
INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);
Вторая вставка уже завершится ошибкой. Для ограничения NULL считается таким же значением, как и любой другой ключ.
CREATE TABLE users (
tenant_id int,
email text,
CONSTRAINT uq_user
UNIQUE NULLS NOT DISTINCT (tenant_id, email)
);
Полезно, когда NULL — это полноценное значение предметной области, а не просто "неизвестно".
🔥 Небольшая возможность PostgreSQL 15, которая позволяет удалить сразу несколько старых костылей вокруг UNIQUE.
➡️ SQL Ready | #совет | 1 527 |
| 8 | +85.000р. получил в январе
+141.000р. пришло в июне
+187.000р. получил в июле
Согласись, похоже на цифры с потолка. Но так сейчас зарабатывает Андрей Д. на запуске контент-заводов для бизнеса.
В 2026 бизнес по всей РФ начал активно внедрять ИИ, чтобы автоматизировать создание текстов, видео и фото для соцсетей и маркетплейсов.
Такие ИИ настраивает Евгений Андрианов с командой.
Андрей присоединился к команде Евгения и за пару недель с нуля научился работать с ИИ. На старте он заработал 85 тыс., а сейчас вышел на более 180 тыс в месяц.
Как это работает:
- Проходишь обучение пару недель;
- Получаешь реальный заказ из базы;
- Собираешь ИИ-контент-завод по формуле;
- Сдаёшь проект — получаешь деньги.
Объём работом выбираешь сам. График свободный. Средний доход участников команды — 92 852р. в месяц.
Не нужно искать клиентов самостоятельно.
Не нужен опыт.
Не требуется техническое образование.
Всё, что нужно для старта — запустить вводный инструктаж на сайте бесплатно.
Осталось 14 мест.
👉 Пробуй
Реклама. ООО "АИМ" ИНН 9723249701 | 1 342 |
| 9 |  Matn yo'q... | 1 550 |
| 10 |  ❤️ Интересная статья на Хабре: «Что такое RAGFlow и с чем его едят»!
В этой статье:
• Разберётесь, как RAGFlow помогает LLM работать с внутренними документами и снижать количество галлюцинаций;
• Узнаете, чем RAGFlow отличается от классического RAG и как он обрабатывает PDF, таблицы, схемы и сканы;
• Посмотрите, как развернуть RAGFlow и использовать его для баз знаний, техподдержки и аналитики.
🔊 Продолжай читать на Habr!
➡️ SQL Ready | #статья | 1 861 |
| 11 |  📂 Шпаргалка по нормализации баз данных в MySQL!
Например, 1NF требует атомарных значений, 2NF избавляет от частичных зависимостей, а 3NF — от транзитивных. Для более сложных схем пригодятся BCNF и 4NF.
На картинке — основные нормальные формы с требованиями, примерами и пользой каждой из них.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс | 1 926 |
| 12 |  +4🖥 PostgreSQL — блокировки строк и конкурентный доступ!
Шпаргалка по механизмам синхронизации параллельных транзакций в PostgreSQL: защита строк от конкурентных изменений и удаления, управление ожиданием и пропуском занятых строк, явная блокировка таблиц и диагностика ожидающих блокировок. Помогает контролировать конкурентный доступ и корректно реализовывать транзакционные сценарии.
➡️ SQL Ready | #шпора | 2 211 |
| 13 |  👨💻 Junior Database — база вопросов и ответов по SQL и базам данных!
В репозитории собраны 27 тем, которые часто встречаются при изучении баз данных и подготовке к техническим собеседованиям: транзакции и ACID, нормализация и денормализация, первичные и внешние ключи, JOIN, GROUP BY и HAVING, индексы, миграции, хранимые процедуры и триггеры. Также затрагиваются оптимизация запросов, партицирование, репликация, шардинг и различия между SQL и NoSQL.
Оставляю ссылочку: GitHub 📱
➡️ SQL Ready | #репозиторий | 2 058 |
| 14 |  📂 SQL в одной шпаргалке!
Например, SELECT, WHERE и ORDER BY отвечают за выборку, фильтрацию и сортировку данных, JOIN связывает таблицы, а GROUP BY, агрегатные и оконные функции помогают анализировать результаты запросов.
На картинке — структурированная карта SQL: от базовых запросов и объединения таблиц до CTE, подзапросов, DDL/DML/DCL/TCL, транзакций и ограничений целостности данных.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс | 2 174 |
| 15 |  Работайте с периодами как с одним значением!
Когда у записи есть start_at и end_at, проверки пересечений быстро превращаются в набор сравнений. В PostgreSQL для этого есть range types: например, tstzrange для диапазона timestamptz.
Вместо:
WHERE start_at < :end_at
AND end_at > :start_at
можно явно работать с диапазонами:
WHERE tstzrange(start_at, end_at, '[)')
&& tstzrange(:start_at, :end_at, '[)')
Оператор && означает «диапазоны пересекаются». [) задаёт полуинтервал: начало включено, конец исключён, поэтому встреча до 12:00 и следующая с 12:00 не считаются пересекающимися.
Но интереснее то, что PostgreSQL умеет проверять диапазоны и другими операторами:
period @> now() -- содержит момент времени
period && :period -- пересекается
period <@ :period -- находится внутри
Если такие проверки выполняются постоянно, диапазон можно хранить непосредственно в таблице и индексировать GiST:
CREATE INDEX bookings_period_idx
ON bookings USING gist (period);
И самое полезное: правило «для одной комнаты интервалы не должны пересекаться» можно перенести из приложения непосредственно в БД:
CREATE EXTENSION IF NOT EXISTS btree_gist;
ALTER TABLE bookings
ADD CONSTRAINT bookings_no_overlap
EXCLUDE USING gist (
room_id WITH =,
period WITH &&
);
Теперь две пересекающиеся брони одной комнаты физически нельзя записать, даже если два конкурентных запроса одновременно прошли предварительную проверку в приложении.
🔥 Range types превращают интервалы времени из пары колонок и ручной логики в полноценный тип данных: его можно сравнивать, индексировать и даже запретить пересечения на уровне констрейнта.
➡️ SQL Ready | #совет | 2 013 |
| 16 |  Очнись, нас готовят к цифровому ГУЛАГу
Уже в десятках регионов России отключают мобильный интернет (даже когда нет атак БПЛА), тестируют «белые списки» и замедляют Телегу.
90% людей тупо смотрят на уплывающий корабль свободного Интернета. Люди поумнее готовятся к новой реальности и читают «Пакет Безопасности».
Здесь дают самые свежие связки для приватности: приложения и утилиты на случай вайтлистов, прокси, браузеры, сервисы — чего тут только нет.
Без шуток, сейчас это один из самых полезных каналов в Телеге. Надеемся на лучшее, но к чему нужно готовиться — вы и сами понимаете: @package_security | 1 077 |
| 17 |  👨💻 Koddo — сайт с теорией и практикой для обучения!
Платформа для изучения SQL через решение реальных задач прямо в браузере. На практике разбираются выборки и фильтрация, GROUP BY и HAVING, JOIN, работа с датами, подзапросы, CTE и оконные функции. Решения автоматически проверяются, а AI-ассистент может дать подсказку, не раскрывая готовый ответ.
📌 Оставляю ссылочку: koddo.ru
➡️ SQL Ready | #ресурс | 1 835 |
| 18 |  +4🖥 Oracle — преобразование и проверка данных!
Шпаргалка по преобразованию и проверке данных в Oracle: работа со строками, числами, датами, временем и Unicode. Используется для явного преобразования типов, форматирования значений, проверки корректности входных данных и обработки символьных данных.
➡️ SQL Ready | #шпора | 2 436 |
| 19 | Временные таблицы: различия между TEMP, CTE и материализацией данных!
В SQL существует несколько способов работать с промежуточными результатами. Основные варианты — временные таблицы, CTE через WITH и обычные подзапросы. Выбор между ними влияет на читаемость запроса, возможность повторного использования данных и работу оптимизатора.
Временная таблица создаётся внутри текущей сессии базы данных и существует до её завершения или до явного удаления. Она подходит для многоэтапной обработки данных, когда результат нужно использовать в нескольких следующих запросах.
CREATE TEMP TABLE monthly_sales AS
SELECT
customer_id,
SUM(amount) AS total_amount
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;
После создания временная таблица становится отдельным объектом базы данных. К ней можно обращаться как к обычной таблице, создавать индексы и выполнять дополнительные операции.
SELECT *
FROM monthly_sales
WHERE total_amount > 10000;
Временные таблицы особенно полезны при сложных процессах обработки данных, где нужно разделить вычисления на несколько этапов и повторно использовать промежуточный результат.
CREATE INDEX idx_monthly_sales_customer_id
ON monthly_sales(customer_id);
CTE (Common Table Expression) создаётся с помощью конструкции WITH и существует только во время выполнения одного SQL-запроса. Он помогает сделать сложную логику более читаемой и структурированной.
WITH monthly_sales AS (
SELECT
customer_id,
SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id
)
SELECT *
FROM monthly_sales
WHERE total_amount > 10000;
В PostgreSQL начиная с версии 12 CTE может быть автоматически встроен оптимизатором в основной запрос. Это называется CTE inlining. В таком случае отдельное промежуточное хранилище данных не создаётся.
WITH active_users AS MATERIALIZED (
SELECT *
FROM users
WHERE status = 'active'
)
SELECT *
FROM active_users;
Основное отличие MATERIALIZED заключается в том, что PostgreSQL принудительно сохраняет результат CTE перед дальнейшей обработкой. Это может быть полезно, если один и тот же результат используется несколько раз или нужно избежать повторного выполнения тяжёлого вычисления.
WITH user_stats AS MATERIALIZED (
SELECT
user_id,
COUNT(*) AS orders_count
FROM orders
GROUP BY user_id
)
SELECT
a.user_id,
a.orders_count
FROM user_stats a
JOIN user_stats b
ON a.user_id = b.user_id;
Однако использование CTE не всегда означает материализацию. PostgreSQL самостоятельно выбирает оптимальный способ выполнения запроса, если не указано MATERIALIZED или NOT MATERIALIZED.
WITH user_stats AS NOT MATERIALIZED (
SELECT
user_id,
COUNT(*) AS orders_count
FROM orders
GROUP BY user_id
)
SELECT *
FROM user_stats;
Если промежуточный результат большой и используется несколько раз в рамках сложного процесса, временная таблица часто подходит лучше. Она позволяет создать индексы, выполнять дополнительные запросы и управлять этапами обработки отдельно.
CREATE TEMP TABLE user_stats AS
SELECT
user_id,
COUNT(*) AS orders_count
FROM orders
GROUP BY user_id;
CREATE INDEX idx_user_stats_user_id
ON user_stats(user_id);
ANALYZE user_stats;
Команда ANALYZE после заполнения временной таблицы помогает PostgreSQL получить актуальную статистику и выбрать более эффективный план выполнения запроса.
Обычный подзапрос существует только внутри конкретного SQL-выражения. Он подходит для локальных вычислений, когда результат нужен только в одном месте и не требуется повторное использование.
SELECT *
FROM (
SELECT
user_id,
COUNT(*) AS orders_count
FROM orders
GROUP BY user_id
) s
WHERE orders_count > 50;
🔥 Выбор подходящего варианта зависит от задачи. CTE обычно используют для повышения читаемости и разделения сложной логики внутри одного запроса. Временные таблицы подходят для многошаговой обработки, больших промежуточных результатов и случаев, когда нужны индексы. Подзапросы удобны для простых локальных вычислений внутри одного SQL-выражения.
➡️ SQL Ready | #практика | 1 749 |
| 20 |  Оффер в IT за 3 дня - да!
Вот такой крутой кейс получился у команды ИИ-ассистента Софи🤘
Пользователь зашел на триал, не заплатил за подписку и успел получить оффер с отклика, который сделал бот.
▫️Направление - бэкенд разработка
▫️3 приглашения на собес за 72 часа
▫️Оффер, с зарплатой на 20.000 больше указанной в резюме
Если тоже хочешь попробовать 3 бесплатных дня в Софи - доступ открыт, регистрируйся здесь. | 1 179 |
