SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
نمایش بیشتر📈 تحلیل کانال تلگرام SQL Ready | Базы Данных
کانال SQL Ready | Базы Данных (@sql_ready) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 17 741 مشترک است و جایگاه 7 336 را در دسته فناوری و برنامهها و رتبه 37 136 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 17 741 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 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)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
GRANT даёт пользователю права на таблицу, а ROLLBACK отменяет изменения в рамках транзакции.
На картинке — 5 групп SQL-команд: от определения структуры до управления доступом.
Сохрани, чтобы не забыть!
➡️ SQL Ready | #ресурсCHECK позволяет задать правила, которым обязана соответствовать каждая строка в таблице. Это удобно, когда нужно гарантировать корректные значения без сторонней логики.
Представим, что мы хотим убедиться, что цена товара всегда больше нуля:
CREATE TABLE products (
product_id SERIAL PRIMARY KEY,
name TEXT,
price NUMERIC(10,2),
CHECK (price > 0)
);
Теперь добавим ограничение, чтобы процент скидки был в пределах от 0 до 100:
ALTER TABLE discounts
ADD CONSTRAINT percent_range_chk
CHECK (percentage BETWEEN 0 AND 100);
И создадим таблицу событий, где дата начала всегда должна быть раньше даты окончания:
CREATE TABLE events (
id SERIAL PRIMARY KEY,
starts_at TIMESTAMP,
ends_at TIMESTAMP,
CHECK (starts_at < ends_at)
);
🔥 Но помните, что CHECK проверяет только вставляемые или обновлённые строки. Если вы добавляете ограничение в таблицу с данными, указывайте NOT VALID, чтобы временно обойти проверку.
➡️ SQL Ready | #практикаУзкое место — не мощность сервера, а эффективность кода и архитектуры запросов.Прокачайте скорость для себя и команды - получите бесплатно тренинг «Аналитика без тормозов» от Георгия Семенова, руководителя из Яндекс Вы узнаете: ✅ Методы ускорения запросов и дашбордов, применимые к любой СУБД ✅ Специфические нюансы оптимизации, которые отличают middle от senior. Но это не всё. Мы понимаем: результат дает прокачка всей команды и внедрение знаний в конкретные рабочие задачи. Симулейтив предлагает корпоративное обучение под ключ: ✅Преподаватели-практики из “биг-теха” адаптируют программу под ваши задачи ✅Выгода до 30% при пакетном команды ✅Рамочный договор и помощь с компенсацией Примените знания уже сегодня, а затем внедрите её в работу всего отдела аналитики - чтобы ваши процессы полетели! Забрать тренинг Реклама. ООО "АЙТИ РЕЗЮМЕ". ИНН 4025460134. erid: 2W5zFJpk4QR
• Почему логика обновить + вставить ломается; • Как зафиксировать правило на уровне базы; • Как условный уникальный индекс предотвращает дубликаты.Подход, который убирает класс ошибок с конкурентным доступом и делает данные консистентными независимо от нагрузки. ➡️ SQL Ready | #гайд
sales(id, revenue, orders_count)
Самый очевидный вариант:
SELECT
id,
revenue / orders_count AS avg_order_value
FROM sales;
На первый взгляд всё нормально. Но как только orders_count = 0, начинаются проблемы: в ряде СУБД такой запрос упадёт с ошибкой.
Обычно в таких местах используют NULLIF:
SELECT
id,
revenue / NULLIF(orders_count, 0) AS avg_order_value
FROM sales;
Что здесь происходит: NULLIF(orders_count, 0) вернёт: orders_count, если это не ноль; NULL, если это ноль.
Соответственно: если знаменатель не ноль — деление выполняется как обычно; если знаменатель ноль — получится NULL.
И это как раз правильное поведение. Потому что NULLIF не исправляет данные и не подменяет ноль каким-то удобным значением. Он просто говорит: в этой строке результат не определён.
Иногда после этого пишут так:
SELECT
id,
COALESCE(revenue / NULLIF(orders_count, 0), 0) AS avg_order_value
FROM sales;
Так делать можно, но только если 0 здесь действительно имеет смысл.
Потому что: NULL — значение не определено; 0 — значение определено и равно нулю. Это разные вещи. И подмена одного другим — уже не технический, а смысловой выбор.
Ещё пример:
SELECT
id,
success_count * 100.0 / NULLIF(total_count, 0) AS success_percent
FROM stats;
Почему именно 100.0, а не 100? Чтобы не получить целочисленное деление в тех СУБД, где дробная часть иначе отбросится.
То же самое можно записать и через CASE:
SELECT
id,
CASE
WHEN orders_count = 0 THEN NULL
ELSE revenue / orders_count
END AS avg_order_value
FROM sales;
Это тоже нормальный вариант. Но когда задача именно в защите от деления на ноль, NULLIF обычно короче и читается быстрее.
Ещё момент, который часто путают:
SELECT
SUM(revenue) / NULLIF(SUM(orders_count), 0) AS avg_order_value
FROM sales;
а также:
SELECT
AVG(revenue / NULLIF(orders_count, 0)) AS avg_order_value
FROM sales;
Это разные расчёты. В первом случае — общая выручка делится на общее число заказов. Во втором — считается среднее от построчных значений, причём AVG пропускает NULL.
🔥 Итог простой: NULLIF(x, 0) — приём, который в реальных запросах спасает. Особенно когда хочется не просто чтобы не упало, а чтобы результат оставался корректным по смыслу.
➡️ SQL Ready | #практикаОставляю ссылочку: GitHub 📱➡️ SQL Ready | #репозиторий
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at DESC)
INCLUDE (total, status);
INCLUDE добавляет дополнительные колонки в индекс (payload), но они не участвуют в поиске и сортировке, часто это выгоднее, чем делать их частью ключа:
SELECT user_id, created_at, total, status
FROM orders
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 1;
Теперь все нужные поля есть в индексе, и PostgreSQL может выполнить запрос через Index Only Scan, уменьшая или исключая обращения к таблице (heap):
EXPLAIN ANALYZE SELECT ...
В плане вы увидите Index Only Scan (иногда с Heap Fetches) вместо Index Scan — это значит, что обращения к таблице сокращены или отсутствуют.
🔥 Один из практических бустов в read-heavy сценариях и частых API-запросах.
➡️ SQL Ready | #советDISTINCT позволяет легко отфильтровать дубликаты на уровне запроса — без дополнительной логики.
Выберем все уникальные города из таблицы клиентов:
SELECT DISTINCT city FROM customers;
Теперь получим только уникальные пары "страна + город":
SELECT DISTINCT country, city FROM customers;
А вот как посчитать количество разных городов:
SELECT COUNT(DISTINCT city) FROM customers;
В PostgreSQL можно выбирать первую уникальную строку по группе значений:
SELECT DISTINCT ON (user_id) *
FROM logins
ORDER BY user_id, login_time DESC;
🔥 DISTINCT полезен для отчётов, списков, фильтрации и аналитики. Но помните: он влияет на производительность — особенно при работе с большими таблицами.
➡️ SQL Ready | #практикаDDL. Хотим изменить данные внутри — используем DML. А если нужно просто вытянуть информацию — поможет DQL с её незаменимым select.
Полезно держать под рукой, чтобы не забыть!
➡️ SQL Ready | #ресурсОсновные функции обработки строк в Oracle SQL: извлечение подстрок, определение позиции подстроки, вычисление длины строки, преобразование регистра, удаление лишних символов по краям, замена фрагментов текста и дополнение строки до заданной длины.
➡️ SQL Ready | #шпора