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

الذهاب إلى القناة على Telegram

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

📈 نظرة تحليلية على قناة تيليجرام SQL Ready | Базы Данных

تُعد قناة SQL Ready | Базы Данных (@sql_ready) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 15 559 مشتركاً، محتلاً المرتبة 8 396 في فئة التكنولوجيات والتطبيقات والمرتبة 43 154 في منطقة روسيا.

📊 مؤشرات الجمهور والحراك

منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 15 559 مشتركاً.

بحسب آخر البيانات بتاريخ 11 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار 56، وفي آخر 24 ساعة بمقدار -9، مع بقاء الوصول العام مرتفعاً.

حالة التحقق: غير موثّقة
معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 12.41‎%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 6.30‎% من ردود الفعل نسبةً إلى إجمالي المشتركين.
وصول المنشورات: يحصل كل منشور على متوسط 1 931 مشاهدة. وخلال اليوم الأول يجمع عادةً 980 مشاهدة.
التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 24.
الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل sql, строка, user_id, created_at, desc.

📝 الوصف وسياسة المحتوى

يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it РКН: https://clck.ru/3QREBc Реклама на бирже: https://telega.in/c/sql_ready”

بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 12 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.

15 559

المشتركون

-924 ساعات

+307 أيام

+5630 أيام

1 931

عرض المشاهدات

~ 98024 ساعات

~ 1 15048 ساعات

12.41%

معدل المشاركة

~ 1

المشاركات في اليوم

Ads index

beta

أرشيف المشاركات

15 559

VACUUM — чистим таблицу и ускоряем работу базы! В большинстве СУБД удалённые или обновлённые строки не удаляются мгновенно, а остаются как «мертвые» записи. Со временем это замедляет запросы и увеличивает размер таблиц — нужна очистка. Сначала удаляем устаревшие записи из таблицы:

DELETE FROM sessions WHERE expired = true;

Однако физически строки всё ещё занимают место. Чтобы освободить пространство и обновить статистику, запускаем:

VACUUM ANALYZE sessions;

Для диагностики можно получить подробный отчёт о процессе очистки:

VACUUM VERBOSE sessions;

🔥 Регулярный VACUUM поддерживает производительность и точность планов запросов. ➡️ SQL Ready | #практика

15 559

Как разработчик решил параллельно найму пилить свои бизнес-проекты с нулевым опытом: дневник с передовой Меня зовут Александр Торбек, И я попал в день сурка: код писать умею, зарплата стабильная. Но в заднице зудит ощущение катастрофического застоя. Поэтому я сделал глупейшую вещь — начал разрабатывать продукты. Без связей, плана и стратегии. В блоге буду фиксировать: — идеи (и почему 90% из них — говно собаки) — что сделал, сколько заработал — мысли айтишника, который впервые думает как продакт, а не как тупой исполнитель Я хочу пройти весь путь от основателя продукта до продажника. И выяснить, смогу ли без бизнес-бэкграунда выйти на уровень дядек в элитных пиджаках. Если тоже хотите создавать свои продукты — посмотрите, как я набиваю шишки первым: @atorbek_it

15 559

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

Anonymous voting

15 559

Передавайте списки значений через массивы вместо длинных IN! Когда из приложения нужно передать список id в SQL, многие пишут IN (... , ... , ...), что увеличивает текст SQL и усложняет работу с prepared statements:

WHERE id IN (1,2,3,4,5,6,7)

PostgreSQL умеет принимать массив и сравнивать его через ANY — это короче и позволяет избежать генерации динамического SQL:

WHERE id = ANY($1)

Приложение просто передаёт массив параметром, а текст запроса остаётся неизменным независимо от длины списка:

SELECT *
FROM users
WHERE email = ANY($1);

На практике полезно явно указывать тип массива ($1::bigint[]), а также помнить, что NULL внутри массива влияет на результат сравнения. 🔥 Этот паттерн особенно удобен для batch-запросов, API-фильтров и массовых выборок, где количество значений может сильно меняться. ➡️ SQL Ready | #совет

15 559

😒 Подборка каналов по информационной безопасности Проверенные каналы по безопасности, которые реально помогают расти. 👍 ZeroDay — Уроки, эксплуатация уязвимостей с нуля 👍 Белый Хакер — Свежие новости из мира ИБ 😎 Бункер Хакера — Статьи, книги, шпаргалки и хакинг 👨‍💻 Серверная Админа — Настройка и уроки по компьютерным сетям 📂 Подписывайся

15 559

🐱 Крутейшая статья вышла на Хабре: «Научил ИИ-агента помнить важное и забывать лишнее в SQLite»! В этой статье:

• Разбирается, почему классический RAG плохо подходит для долгоживущих AI-агентов;
• Показана архитектура когнитивной памяти на SQLite: граф узлов и рёбер, сущности, гибридный поиск и механизм разрешения конфликтов знаний;
• Объясняется, как реализовать память агента с механизмом забывания и консолидацией фактов.

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

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

15 559

SEMI JOIN через EXISTS — как корректно проверять наличие связанных строк! Частая задача в SQL — выбрать строки из одной таблицы, если в другой таблице существует хотя бы одна связанная запись. Таблицы:

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

Нужно получить клиентов, у которых есть хотя бы один заказ. Попытка через JOIN:

SELECT
    c.id,
    c.name
FROM customers c
JOIN orders o
  ON o.customer_id = c.id;

Запрос вернёт клиентов, но если у клиента несколько заказов, он появится в результате несколько раз. Чтобы убрать дубликаты, часто добавляют DISTINCT:

SELECT DISTINCT
    c.id,
    c.name
FROM customers c
JOIN orders o
  ON o.customer_id = c.id;

Результат будет корректным, однако такой запрос выражает задачу менее точно: JOIN формирует строки для каждого совпадения, а DISTINCT затем устраняет повторяющиеся значения. В подобных задачах фактически требуется semi join — вернуть строку из customers, если существует хотя бы одна связанная строка в orders. В большинстве СУБД это обычно выражают через EXISTS:

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

Подзапрос проверяет наличие хотя бы одной строки в orders, связанной с текущим клиентом. Оптимизатор часто может завершить проверку сразу после нахождения первого совпадения, поэтому EXISTS является естественным инструментом для проверки существования строк. Практический пример — клиенты, которые делали заказы после определённой даты:

SELECT
    c.id,
    c.name
FROM customers c
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.customer_id = c.id
      AND o.created_at >= '2025-01-01'
);

EXISTS не возвращает данные из подзапроса — он только проверяет факт существования строки. Поэтому внутри обычно пишут:

SELECT 1

или:

SELECT *

В контексте EXISTS список выбираемых выражений не влияет на результат. 🔥 EXISTS — стандартный и выразительный способ реализовать semi join. Он точно отражает намерение запроса и часто позволяет оптимизатору построить более эффективный план выполнения. ➡️ SQL Ready | #практика

15 559

3 дня. 60 откликов. 1 оффер. Очень интересный кейс произошёл у команды Софи — ии-ассистента для поиска работы. К ним в поддержку написала девушка, которая отписалась от продукта ещё месяц назад:

«Мне прислали оффер!»

Начали разбираться — оказывается, она пользовалась только 3 тестовыми днями. То есть за 3 дня ии-ассистент успел сделать 60 откликов. Потом она отписалась. А уже позже — из этих откликов её позвали на интервью, и одно из них привело к офферу.

«Оффер с той вакансии, куда я сама никогда бы не откликнулась.»

Изначально Аня отменила подписку, так как было дорого. Ребята честно спросили у Ани, считает ли она теперь, что подписка стоит своих денег — и получили утвердительный ответ. И в очередной раз убедились: пока ты боишься, Софи делает. В этом ее сила. Совсем скоро ребята откроют набор на бесплатный тест. Места будут ограничены. Подписывайся, чтобы не пропустить ⏳

15 559

❤️ RusauSQL — подробный учебник по SQL для тестировщиков и разработчиков! Это большой гайд по SQL, где последовательно объясняется, как работать с базами данных и писать запросы. На сайте разбираются фундаментальные вещи: что такое SQL, как устроены таблицы и базы данных, как выполнять запросы, проверять данные и взаимодействовать с сервером через язык запросов. Отличный ресурс, если хочешь разобраться в SQL с практической стороны и понять работу баз данных. 📌 Оставляю ссылочку: rusau.net ➡️ SQL Ready | #сайт

15 559

Атомарное перемещение данных между таблицами! Иногда нужно архивировать старые данные: удалить их из основной таблицы и одновременно сохранить в архиве. Многие делают это двумя запросами (INSERT => DELETE):

DELETE FROM orders
RETURNING *

RETURNING позволяет сразу вернуть удалённые строки как результирующий набор, не выполняя повторный SELECT.

WITH moved AS (...)

CTE превращает результат удаления во временный набор данных, который можно использовать в следующей операции:

INSERT INTO orders_archive
SELECT * FROM moved;

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

15 559

Как бигтехи кошмарят вас на собеседованиях Успешно пройти секцию по профильным хардам, но смачно опозориться на логической задаче с часами? Классика бигтеха Автор этой истории побывал на собесе в ❤️ и рассказал всю правду о клоунаде, которая там происходила Вита Заебумба | Путь корпората — топовый канал про IT, сферу найма, трешовые собесы и работу в корпорациях. Просто кладезь кулстори не только от автора, но и от подписчиков Истории, которые уже успели стать бестселлером: — Поймала интервьюеров за руку на собесе в Ягодках 🛍 — Что будет с рынком найма в 2026 году + полезные материалы — Эффект Писюхи, или как я столкнулась с эйджизмом в найме — Aston, разлогинься, или как продать свою жопу в рабство — Если твой руководитель ведет себя так, беги оттуда Но тут не только про поржать. Здесь вы узнаете: 🔹Как писать резюме так, чтобы вас звали, а не морозили 🔹Что вообще происходит с рынком 🔹Как обойти 90% кандидатов 🔹Как не продешевить и не выйти с собеса с чувством, что вас поимели Подписывайтесь на @vitazaebymba

15 559

📂 Напоминалка по SQL JOIN! Например, LEFT JOIN позволяет получить все строки из левой таблицы, даже если соответствующих записей в правой таблице нет, а FULL OUTER JOIN возвращает все строки из обеих таблиц, заполняя отсутствующие значения NULL. На изображении показаны 4 основных типа SQL JOIN, которые чаще всего используются при объединении данных из нескольких таблиц. 📌 Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

15 559

🖥 Анализ средней длительности сессий пользователей по устройствам! В этой задаче напишем SQL-запрос, который поможет вычислить среднее время сессии для пользователей на разных устройствах за последние 30 дней. Что делаем:

• Фильтруем сессии по времени и устройствам. • Считаем длительность каждой сессии. • Группируем и находим среднее время по типам устройств.

Такой анализ помогает понять, в каких моментах сфокусироваться на улучшении UX и маркетинговых кампаниях. ➡️ SQL Ready | #задача

15 559

Забудь про ChatGPT. Это как просить калькулятор нарисовать картину. Пока массы гоняют одни и те же скучные запросы в зацензуренные боты, реальная революция ИИ в канале «Техноразум»: — Нейросети, которые не боятся запретных тем ( 🔞) — Скрытые функции, которые другие ИИ прячут за платную подписку или цензурой — Настоящие инструкции и промты для взлома творческих шаблонов Переходи к настоящим возможностям, забудь про детский сад нейросетей: https://t.me/+ykoDhAfKfWRiODVi

15 559

💡 Rows — умные таблицы с встроенным ИИ! Сервис для работы с данными в формате таблиц (аналог Excel / Google Sheets) с интегрированными AI-инструментами. Позволяет анализировать данные, создавать формулы по описанию и подтягивать информацию из интернета и API. Подходит для аналитики, автоматизации и обработки больших массивов данных. 📌 Оставляю ссылочку: rows.com ➡️ SQL Ready | #ресурс

15 559

Агрегирование по группам с оконными функциями! Когда нужно посчитать агрегаты по группе и при этом сохранить исходные строки, многие делают подзапрос с GROUP BY и потом джойнят его обратно:

SUM(o.total) OVER (PARTITION BY o.user_id)

Оконная функция считает агрегат по группе, но не схлопывает строки, поэтому не нужен ни GROUP BY, ни повторное соединение:

AVG(o.total) OVER (PARTITION BY o.user_id)

Можно получить любые метрики по той же группе в одном проходе по данным:

COUNT(*) OVER (PARTITION BY o.user_id)

Особенно полезно для аналитики, отчётов, флагов “у пользователя больше N заказов” и подобных задач без лишних подзапросов. 🔥 Один из самых эффективных способов упростить сложные запросы. ➡️ SQL Ready | #совет

15 559

🤬Chat GPT отключат в РФ Офицальная причина была озвучена такая "Они нагружают систему, но купить платную версию не могут из-за своего местоположения". Другие крупные ИИ-сервисы начинают подхватывать эту политику. Чтоб не стать жертвой изоляции рунета, просто сохрани канал Доктор GPT - мы уже готовим обходку к новой системе безопасности. Не жди бана, подпишись: @gpt

15 559

☕️ Полезную статью нашёл на Хабре: «Инженерная история: добавляем 3-ю СУБД в карточный процессинг»! В этой статье:

• Разобрано, зачем в высоконагруженной системе может понадобиться сразу несколько СУБД и как между ними строится абстрактный слой доступа к данным;
• Показан опыт интеграции распределённой базы данных YDB в существующую архитектуру;
• Разбираются технические нюансы: батч-операции, строгая типизация запросов, особенности драйверов и результаты нагрузочного тестирования.

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

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

15 559

Почему OFFSET может ломать производительность пагинации? OFFSET выглядит удобно для страниц, но база всё равно должна просканировать и пропустить все предыдущие строки. Поэтому чем дальше страница, тем медленнее запрос:

OFFSET 100000

Даже если вы не видите эти строки, СУБД всё равно читает их из индекса или таблицы, поэтому время выполнения растёт вместе с OFFSET:

SELECT *
FROM orders
WHERE id > :last_seen_id
ORDER BY id
LIMIT 10;

Эффективнее использовать keyset-pagination — продолжать выборку от последнего значения ключа, а не пропускать строки:

WHERE id > :last_seen_id

:last_seen_id — это id последней строки предыдущей страницы. Такой запрос использует индекс напрямую (если id индексирован, обычно это PK), поэтому работает одинаково быстро на первой и на миллионной странице. Если сортировка не уникальная (например created_at), добавляйте tie-breaker:

ORDER BY created_at, id
WHERE (created_at, id) > (:last_seen_created_at, :last_seen_id)

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