SQL Ready | Базы Данных
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Cотрудничество: @energy_c РКН: https://clck.ru/3QREBc
Ko'proq ko'rsatish📈 Telegram kanali SQL Ready | Базы Данных analitikasi
SQL Ready | Базы Данных (@sql_ready) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 17 754 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 7 324-o'rinni va Rossiya mintaqasida 37 073-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 17 754 obunachiga ega bo‘ldi.
19 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 712 ga, so‘nggi 24 soatda esa 32 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 12.57% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 5.99% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 230 marta ko‘riladi; birinchi sutkada odatda 1 062 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 23 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent sql, строка, users, индекс, user_id kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Авторский канал про Базы Данных и SQL
Ресурсы, гайды, задачи, шпаргалки.
Информация ежедневно пополняется!
Cотрудничество: @energy_c
РКН: https://clck.ru/3QREBc”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 20 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
LAG(), она возвращает значение из предыдущей строки в рамках группы:
LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at)
Сравни текущее значение с предыдущим:
status <> LAG(status) OVER (...)Получается булево поле —
true, когда статус поменялся.
Хочешь вывести только моменты изменения, просто оберни в подзапрос:
SELECT *
FROM (
SELECT order_id, status, updated_at,
status <> LAG(status) OVER (PARTITION BY order_id ORDER BY updated_at) AS changed
FROM order_status_log
) t
WHERE changed;
🔥 Это основа для аудита изменений и аналитики событийных логов.
➡️ SQL Ready | #совет• Находим средние значения метрик; • Считаем ковариацию и дисперсии; • Собираем финальную формулу корреляции прямо в запросе.Это помогает быстро проверять гипотезы, оценивать результаты и находить зависимости. ➡️ SQL Ready | #задача
WITHIN GROUP решает это, задавая порядок элементов внутри агрегатной функции.
Пример: соберём список продуктов по категории в порядке убывания продаж:
SELECT
category_id,
LISTAGG(product_name, ', ') WITHIN GROUP (ORDER BY total_sales DESC) AS top_products
FROM product_sales
GROUP BY category_id;
В отличие от ARRAY_AGG(product_name ORDER BY ...), синтаксис WITHIN GROUP используется для ordered-set функций, а не для любых агрегатов.
Пример вычисления порогового значения 90% по сумме заказов по регионам:
SELECT
region_id,
PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY total_amount) AS p90_sales
FROM orders
GROUP BY region_id;
PERCENTILE_CONT() и PERCENTILE_DISC() позволяют вычислять медиану или любое процентное значение без оконных функций.
Медиана чека по каждому магазину:
SELECT
store_id,
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY total_amount) AS median_check
FROM orders
GROUP BY store_id;
Такой подход может быть проще и эффективнее, чем использование NTILE() или RANK() в оконных выражениях.
🔥 Используйте WITHIN GROUP, когда важен порядок в агрегатах.
➡️ SQL Ready | #практикаВ этой шпаргалке собраны основные приёмы работы с временными данными в SQL Server: создание, заполнение, очистка и удаление временных таблиц, а также использование табличных переменных. Эти методы помогают выполнять промежуточные расчёты, строить отчёты и оптимизировать сложные запросы без изменения основной схемы базы.
➡️ SQL Ready | #шпора• Храним шаблоны фраз и ответы в таблице responses; • Используем ILIKE, чтобы находить ключевые слова в сообщении; • Возвращаем лучший ответ по приоритету совпадений.Приём показывает, что SQL способен работать не только с числами, но и с текстом, превращаясь в мини-экспертную систему. ➡️ SQL Ready | #задача
BEGIN — всё, что дальше, идёт как единое целое:
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
Если что-то падает, делай rollback, и база возвращается к исходному состоянию.
Не забывай: каждая открытая транзакция держит блокировки. Чем дольше она живёт, тем выше шанс конфликтов.
Контролируй уровень изоляции - баланс между скоростью и безопасностью:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
🔥 Производительность БД начинается с правильного управления транзакциями и блокировками.
➡️ SQL Ready | #советUSING помогает сократить код и избежать дублирования столбцов.
Объединим заказы и клиентов по общему полю:
SELECT *
FROM orders
JOIN customers USING (customer_id);
То же самое через ON выглядело бы чуть длиннее и менее лаконично:
SELECT *
FROM orders
JOIN customers ON orders.customer_id = customers.customer_id;
С USING SQL сам убирает дубликаты полей, оставляя одно customer_id в результирующем наборе.
Можно соединять и по нескольким ключам:
SELECT *
FROM orders
JOIN shipments USING (order_id, customer_id);
Пример из аналитики: посчитаем сумму заказов по каждому клиенту:
SELECT customer_id,
c.customer_name,
SUM(o.amount) AS total_amount
FROM customers c
JOIN orders o USING (customer_id)
GROUP BY customer_id, c.customer_name
HAVING SUM(o.amount) > 1000
ORDER BY total_amount DESC;
🔥 Используйте USING, когда имена ключей совпадают — это приём, который улучшает читаемость и уменьшает вероятность ошибок.
➡️ SQL Ready | #практикаВ этой шпаргалке собраны основные оконные функции Oracle SQL, применяемые для аналитики, ранжирования и работы с порядком строк без свёртки данных. Они вычисляют значения в контексте "окна" — набора строк, связанных с текущей строкой. Это мощный инструмент для аналитических отчётов и сложных выборок.
➡️ SQL Ready | #шпораINCLUDE решает это: добавляет нужные колонки в индекс и превращает Index Scan в Index Only Scan.
Сегодня в посте:
• Как работает INCLUDE и почему это не дублирование; • Как проверить, что запрос действительно читает только индекс; • Где Covering Index даёт реальный прирост.Производительность начинается не с кода, а с структуры индекса. ➡️ SQL Ready | #гайд
DISTINCT не всегда подходит: он не умеет выбирать, какая строка «главная». В PostgreSQL есть мощный приём — DISTINCT ON.
Создадим таблицу:
CREATE TABLE users (
id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
email TEXT NOT NULL,
login_count INT,
created_at TIMESTAMP DEFAULT now()
);
Добавим данные:
INSERT INTO users (email, login_count, created_at) VALUES
('alice@mail.com', 5, '2024-01-01'),
('alice@mail.com', 8, '2024-03-01'),
('bob@mail.com', 2, '2024-02-01');
Теперь выберем только последнюю запись на каждый email:
SELECT DISTINCT ON (email)
email, login_count, created_at
FROM users
ORDER BY email, created_at DESC, id DESC;
Результат:
email | login_count | created_at
----------------+--------------+----------
alice@mail.com | 8 | 2024-03-01
bob@mail.com | 2 | 2024-02-01
🔥 DISTINCT ON берёт по одной строке на группу, а ORDER BY задаёт, какая именно — последняя, первая или с нужным приоритетом.
➡️ SQL Ready | #практика• Считаем количество живых соседей для каждой клетки; • Применяем правила “жизни” и получаем следующее поколение; • Наблюдаем, как база данных буквально оживает на глазах.Такой приём демонстрирует, что SQL может быть не только инструментом аналитики, но и полноценной средой моделирования. ➡️ SQL Ready | #задача
VIEW, но результат хранится физически в таблице):
CREATE MATERIALIZED VIEW daily_stats AS
SELECT date(created_at) AS day,
COUNT(*) AS total_orders
FROM orders
GROUP BY 1;
CREATE UNIQUE INDEX ON daily_stats(day); -- нужно для CONCURRENTLY
Обновлять можно вручную или по расписанию (cron, pg_cron):
REFRESH MATERIALIZED VIEW_stats;
А если нужно без блокировок чтения:
REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats;
🔥 Помни: concurrently медленнее и требует индекс, но позволяет читать данные во время обновления.
➡️ SQL Ready | #совет• Как создать таблицу с RANGE-партициями; • Почему фильтры по ключу в разы ускоряют SELECT; • Как безопасно удалять старые данные за миллисекунды.Это инструмент архитектуры, а не оптимизации, если он внедрён правильно таблица работает быстро. ➡️ SQL Ready | #гайд
