SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
نمایش بیشتر📈 تحلیل کانال تلگرام SQL Ready | Базы Данных
کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 17 719 مشترک است و جایگاه 7 336 را در دسته فناوری و برنامهها و رتبه 37 136 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 17 719 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 18 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 696 و در ۲۴ ساعت گذشته برابر 5 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 12.57% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 6.05% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 2 222 بازدید دریافت میکند. در اولین روز معمولاً 1 069 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 23 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند sql, строка, users, индекс, user_id تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 19 اکتبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
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 | #совет• Разобрано, зачем в высоконагруженной системе может понадобиться сразу несколько СУБД и как между ними строится абстрактный слой доступа к данным;
• Показан опыт интеграции распределённой базы данных YDB в существующую архитектуру;
• Разбираются технические нюансы: батч-операции, строгая типизация запросов, особенности драйверов и результаты нагрузочного тестирования.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
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 | #советОставляю ссылочку: GitHub 📱➡️ SQL Ready | #репозиторий
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 | #практикаSELECT, UPDATE или другой SQL, СУБД сначала обрабатывает его внутренне, а уже потом выполняет.
На схеме — путь запроса: приём — разбор (парсер) — оптимизация — выполнение — доступ к данным — буферы, транзакции и блокировки — чтение/запись (память или диск).
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурс• Показано, как реализовать полноценную игру, от хранения состояния до рендеринга 3D-сцены — средствами одной лишь базы данных;
• Разобрана архитектура, игровой цикл на транзакциях и многопользовательская синхронизация через SQL;
• На реальном проекте демонстрируются неожиданные возможности СУБД далеко за пределами типичных CRUD-задач.
🔊 Продолжайте читать на Habr!➡️ SQL Ready | #статья
Основные функции и приёмы работы с календарными значениями в Oracle: получение текущих даты и времени на стороне БД, вычисление интервалов, смещение по месяцам, усечение до нужной гранулярности, извлечение компонентов даты, а также корректное преобразование строк в DATE и TIMESTAMP. Полезно для отчётов, аналитики, планирования, ETL-процессов и любой логики, связанной с датами и временем.
➡️ SQL Ready | #шпора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 | #практикаu.email = b.email AND u.phone = b.phone
SQL умеет сравнивать кортежи целиком (row value), поэтому несколько колонок можно проверить одним выражением:
(email, phone)
Поддержка зависит от СУБД. Учитывайте поведение NULL и наличие составных индексов, оптимизация не всегда идентична AND.
🔥 Это особенно полезно при фильтрации, дедупликации, проверке попадания в списки, синхронизации таблиц и миграциях данных.
➡️ SQL Ready | #совет