Не попадись на ботовода! Telemetrio знаходить і позначає такі канали мітками 👉 Хочеш бачити мітку, оформляй підписку

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

Відкрити в Telegram

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

Росія37 136 Технології та додатки7 336...

📈 Аналітичний огляд Telegram-каналу SQL Ready | Базы Данных

Канал SQL Ready | Базы Данных (@sql_ready) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 17 719 підписників, посідаючи 7 336 місце в категорії Технології та додатки та 37 136 місце у регіоні Росія.

📊 Показники аудиторії та динаміка

З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 17 719 підписників.

За останніми даними від 18 жовтня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 696, а за останні 24 години на 5, загальне охоплення залишається високим.

Статус верифікації: Не верифікований
Рівень залученості (ER): Середній показник залученості аудиторії становить 12.57%. Протягом перших 24 годин після публікації контент зазвичай збирає 6.05% реакцій від загальної кількості підписників.
Охоплення публікацій: В середньому кожен допис отримує 2 222 переглядів. Протягом першої доби публікація в середньому набирає 1 069 переглядів.
Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 23.
Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як sql, строка, users, индекс, user_id.

📝 Опис та контентна політика

Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc”

Завдяки високій частоті оновлень (останні дані отримано 19 жовтня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.

17 719

Підписники

+524 години

+1807 днів

+69630 днів

2 222

Перегляди допису

~ 1 06924 години

~ 1 29948 годин

12.57%

Коефіцієнт залучення

~ 1

Дописів на день

Ads index

beta

Архів дописів

17 719

🖥 SCD2 — хранение истории изменений в таблицах! При прямом UPDATE данные теряют историю: невозможно корректно восстановить состояние сущности на дату или отследить момент изменения. Сегодня в гайде:

• Как моделировать версионные данные через valid_from / valid_to; • Как корректно закрывать предыдущую версию и создавать новую; • Как получать актуальное состояние и исторические срезы без дополнительной логики.

SCD Type 2 хранит каждое изменение как отдельную версию строки с фиксированным интервалом актуальности. ➡️ SQL Ready | #гайд

17 719

Слили в телеграмм тонны инфы и отсортировали по каналам 🖥 Курсы & GitHub — 1579ГБ ⌨️ Python — 955ГБ 🤒 OSINT — 315ГБ ☁️ Хакинг & ИБ — 756ГБ 🙃 Linux & Bash — 459ГБ 😦 Работа в IT — 778ГБ 🖥 Общий архив — 2346ГБ ➡️ Практические инструкции, курсы, книги и инструменты.

17 719

😎 Сodedokode/pasta — теория + задачи на практике! Репозиторий с понятным и структурированным разбором баз данных на русском языке. Здесь разобраны ключевые концепции SQL для MySQL и PostgreSQL, есть примеры запросов и задачи для самостоятельной работы. Отлично подходит для укрепления базы и подготовки к собеседованиям.

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

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

17 719

LEFT JOIN и WHERE — классическая ловушка с NULL! LEFT JOIN используют, когда нужно сохранить строки из левой таблицы, даже если в правой нет совпадений. Но одно неверное условие в WHERE — и LEFT JOIN незаметно превращается в INNER JOIN. Таблицы:

users(id, email)
orders(id, user_id, amount)

Нужно получить всех пользователей и их заказы (если есть):

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id;

Если у пользователя нет заказов, поля из orders будут NULL — это ожидаемое поведение LEFT JOIN. Теперь типичная ошибка:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Условие в WHERE отфильтровывает строки, где o.amount IS NULL. В результате пользователи без заказов исчезают, и запрос фактически работает как INNER JOIN. Правильный вариант — переносить условия на правую таблицу в ON:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
   AND o.amount > 100;

Теперь: пользователи без заказов остаются в результате, фильтрация применяется только к связанным строкам orders. Если же логика действительно требует убрать пользователей без заказов, тогда честнее писать INNER JOIN:

SELECT
    u.id,
    u.email,
    o.amount
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.amount > 100;

Так намерение запроса читается однозначно. 🔥 Условия в WHERE применяются после JOIN и могут уничтожить строки с NULL. Условия в ON влияют только на логику связывания таблиц. ➡️ SQL Ready | #практика

17 719

⚡ Повысить производительность СУБД или сократить расходы на IT-инфраструктуру? Не нужно выбирать. Selectel расскажет и покажет, как найти баланс на примере собственного сервиса. Подключайтесь к бесплатному вебинару для тех, кто работает с базами данных 🗓 5 февраля, 12:00 📍 Онлайн Вы узнаете: - как работают базы данных на выделенном облачном сервере, - какие особенности архитектуры позволяют повысить производительность сервиса в 10 раз и получить до 1,5 млн IOPS и 7000 Мб/c в облаке, - как клиентам Selectel удается экономить до 47% на IT-инфраструктуре. Регистрируйтесь по ссылке: https://slc.tl/27v33 👉 Чтобы не пропустить новые мероприятия, воркшопы и бесплатные курсы Selectel, подписывайтесь на @selectel_events Реклама. АО "Селектел". erid:2W5zFJj73Gc

17 719

❤️ AlgoTree — понятные объяснения алгоритмов, деревьев и графов! Этот сайт помогает анализировать структуры данных: деревья, графы, обходы и множество другого. Здесь нет решений задач или подготовкой к собеседованиям, упор именно на понимание того, как и почему всё устроено. Материал подается последовательно и концептуально, поэтому хорошо подходит даже новичкам. 📌 Оставляю ссылочку: algotree.org ➡️ SQL Ready | #ресурс

17 719

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

• Сравним бронирования одного ресурса между собой, не создавая дубликатов; • Проверим пересечение временных интервалов с помощью канонического условия; • Получим список конфликтующих бронирований, которые система должна блокировать.

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

17 719

Как получить «последнюю запись на группу»? Очень частая задача - взять последнюю запись на пользователя, заказ, сущность. Многие делают это с ROW_NUMBER(), хотя Postgres умеет проще:

SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;

DISTINCT ON оставляет первую строку в рамках группы, а порядок задаётся через ORDER BY:

ORDER BY user_id, created_at DESC

Так первой будет именно самая свежая запись. Если возможны одинаковые created_at, лучше явно добавить тай-брейкер:

ORDER BY user_id, created_at DESC, id DESC

Если нужно выбрать конкретные поля и избежать SELECT *, просто укажите нужные колонки:

SELECT DISTINCT ON (user_id)
       user_id, id, created_at
FROM orders
ORDER BY user_id, created_at DESC, id DESC;

Выражения из DISTINCT ON (...) обязаны быть левым префиксом ORDER BY, иначе Postgres выдаст ошибку. 🔥 Такой запрос часто читается проще, чем ROW_NUMBER(), и при подходящем индексе (user_id, created_at DESC, id DESC) может давать отличный план выполнения. ➡️ SQL Ready | #совет

17 719

Секрет, который делит январь на «до» и «после» в карьере. В январе есть два типа соискателей:

99% — обновляют резюме, рассылают его в 100 компаний и ждут. Они получают тишину или вежливые отказы. 1% — используют «окно возможностей». Они знают, что мало просто найти вакансии. Нужно пройти так, чтобы рекрутер не мог вас пропустить.

Разница не в опыте. Разница в методе. Мы в @mathcareer — про метод. Мы не даём «советы», а разбираем систему: как читать вакансию между строк, что писать в сопроводительном письме, которое откроет двери, и как вести переговоры. Хотите перейти из 99% в 1%? 👉 Всё уже разложено по полочкам здесь: https://t.me/+v5AE1DRA7L04MGVi

17 719

🖥 Поиск дубликатов и ранжирование данных!

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

➡️ SQL Ready | #шпора

17 719

Настроил чат-бота за пару часов → заработал 9 000₽. Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу. А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени. Разница в зарплате: 200 тысяч. И нет — не надо ничего программировать. Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе. Без опыта. За 3-4 часа. 💡 Суть проста: Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги. В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно. Всё, что нужно для старта — запустить бота 👉 @other_digital_bot Там пошаговый план как стартануть и гайд по клиентам. До 26 января вход бесплатный.

17 719

💡 На Хабре вышла мега годная статья: «Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99%»! В этой статье:

• О системе обработки огромного потока форм — от поиска до подачи объявлений;
• Подробно объясняется, зачем команде нужен уровень надёжности SLI 99.99%;
• Описаны оригинальные подходы к версионированию данных, изоляции изменений;
• Приводятся реальные схемы работы с SQL/NoSQL, кэшами и стратегиями graceful degradation при отказах.

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

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

17 719

Знали, что агрегаты можно фильтровать без CASE и подзапросов? Многие пишут COUNT(CASE WHEN ...), хотя в SQL (например, в PostgreSQL) есть более декларативный способ - FILTER. Фильтрация применяется к агрегатной функции, а не ко всей выборке:

COUNT(*) FILTER (WHERE status = 'paid')

Строки не исключаются из FROM, а учитываются только внутри конкретного агрегата. Можно считать несколько независимых метрик за один проход по таблице:

COUNT(*) FILTER (WHERE status = 'failed')

Оптимизатор обычно сводит такой запрос к линейному плану. FILTER работает не только с COUNT, но и с другими агрегатами:

SUM(amount) FILTER (WHERE status = 'paid')

🔥 FILTER выразит намерение напрямую: агрегат считает только нужные строки, без лишней логики. ➡️ SQL Ready | #совет

17 719

Изоляция рунета ближе, чем ты думаешь

Loading … ██████████████] 99%

Роскомнадзору дали карт-бланш на блокировки, а «белые списки» сайтов тестируют уже в десятках регионов. И гайки будут закручиваться только сильнее. Чтобы в одночасье не лишиться доступа к свободному Интернету, просто сохрани Only Hack. Тут профессиональный хакер делится фишками, с которыми доступ к глобальной сети у тебя будет даже в случае ядерного апокалипсиса. Не жди момента «Х». Перестрахуйся подпиской.

17 719

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

Anonymous voting

17 719

Email должен быть уникальным только для активных пользователей? Большинство реализуют это проверками в коде, SELECT перед INSERT, транзакциями или триггерами. PostgreSQL умеет делать это на уровне индекса:

INSERT INTO users (email) VALUES ('a@b.com');

Сработает, если активного пользователя с таким email ещё нет:

UPDATE users SET deleted_at = now() WHERE email = 'a@b.com';

Теперь email снова можно использовать для активных, без физического удаления строк. 🔥 Partial UNIQUE index — отличный способ фиксировать правила прямо в PostgreSQL. ➡️ SQL Ready | #совет

17 719

🚀 Yandex B2B Tech запускает сервис Managed Sharded PostgreSQL для горизонтального масштабирования PostgreSQL PostgreSQL — самая популярная open-source СУБД, которой сегодня пользуются 55,6% профессиональных разработчиков. Но одна из главных её ограничений — отсутствие встроенного горизонтального масштабирования, что критично при обработке больших объемов данных. Yandex B2B Tech решила эту задачу, запустив сервис , который позволяет шардировать PostgreSQL — то есть распределять данные по нескольким серверам. Это ускоряет работу систем, снижает риски и сокращает время вывода продуктов на рынок в 3-4 раза. Технология уже проверена в реальных проектах Яндекса, таких как Яндекс ID, Яндекс Пэй и Едадил, а также успешно используется внешними клиентами. Managed Sharded PostgreSQLдоступен на облачной платформе Yandex Cloud и помогает банкам и ритейлерам обрабатывать миллионы транзакций быстрее и надежнее. Подробнее — ссылка

17 719

👍 DataLemur — задачи для практики и подготовки к собеседованиям! На сайте собраны вопросы разного уровня сложности: от базовых запросов до задач с JOIN, GROUP BY, подзапросами и оконными функциями. Формат ориентирован на реальные кейсы, такие задачи часто встречаются в работе и на собеседованиях. Удобный ресурс, чтобы закрепить знания. 📌 Оставляю ссылочку: datalemur.com ➡️ SQL Ready | #ресурс