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

رفتن به کانال در Telegram

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

نمایش بیشتر

روسيا43 154 فناوری و برنامه‌ها8 396...

📈 تحلیل کانال تلگرام SQL Ready | Базы Данных

کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 15 559 مشترک است و جایگاه 8 396 را در دسته فناوری و برنامه‌ها و رتبه 43 154 را در منطقه روسيا دارد.

📊 شاخص‌های مخاطب و پویایی

از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 15 559 مشترک جذب کرده است.

بر اساس آخرین داده‌ها در تاریخ 11 ژوئن, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 56 و در ۲۴ ساعت گذشته برابر -9 بوده و همچنان دسترسی گسترده‌ای حفظ شده است.

وضعیت تأیید: تأیید نشده
نرخ تعامل (ER): میانگین تعامل مخاطب 12.41% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 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 | #совет