7786
Авторский канал про Базы Данных и SQL Ресурсы, гайды, задачи, шпаргалки. Информация ежедневно пополняется! Автор: @energy_it
Настроил чат-бота за пару часов → заработал 9 000₽.
Просто представь, кто-то стоит в очереди на маршрутку в 8 утра чтобы успеть на “любимую” работу.
А кто-то за 3-4 часа делает чат-бота со своего ноута без привязки ко времени.
Разница в зарплате: 200 тысяч.
И нет — не надо ничего программировать.
Зачем грузить мозги кодом, если можно собрать чат-бота для бизнеса на конструкторе.
Без опыта. За 3-4 часа.
💡 Суть проста:
Берёшь клиента → Собираешь бота по шаблону → Наставник всё проверяет → Сдаёшь работу и получаешь деньги.
В первый месяц обычно выходят на доход 50–80 тыс ₽/мес, а с опытом от 180 тыс ₽ и выше. Легко совмещается с работой, учёбой, рыбалкой, семейными хлопотами… график устанавливаешь самостоятельно.
Всё, что нужно для старта — запустить бота
👉 @other_digital_bot
Там пошаговый план как стартануть и гайд по клиентам.
До 27 июля вход бесплатный.
😍 CitForum Database — большая база материалов по SQL и СУБД!
На сайте собрана крупная библиотека материалов по базам данных: SQL, проектирование БД, транзакции, индексы, оптимизация запросов и администрирование различных СУБД. Здесь можно найти статьи, учебные пособия, техническую документацию и обзоры по PostgreSQL, MySQL, Oracle, Microsoft SQL Server и другим системам управления базами данных.
📌 Оставляю ссылочку: citforum.ru
➡️ SQL Ready | #ресурс
Индексы по выражениям — ускоряем поиск по вычисляемым значениям!
Обычный индекс работает только тогда, когда база может сравнить значение напрямую с колонкой. Если в условии WHERE применяется функция к полю, оптимизатор часто не может использовать обычный индекс.
Таблица:
users(id, email)
CREATE INDEX idx_users_email
ON users(email);
SELECT *
FROM users
WHERE email = 'test@mail.com';
LOWER():SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';
LOWER() к каждой строке, а потом сравнить результат. Обычный индекс по email для такого условия уже не подходит.CREATE INDEX idx_users_lower_email
ON users(LOWER(email));
EXPLAIN ANALYZE
SELECT *
FROM users
WHERE LOWER(email) = 'test@mail.com';
CREATE INDEX idx_orders_year
ON orders(EXTRACT(YEAR FROM created_at));
INSERT/UPDATE и занимают место.WHERE, JOIN или ORDER BY.
📂 Напоминалка по SQL JOIN и объединению данных!
Например, INNER JOIN возвращает только совпадающие записи, LEFT/RIGHT JOIN сохраняют данные одной из сторон, а FULL JOIN объединяет полный набор данных из обеих таблиц. Дополнительные проверки через NULL позволяют находить отсутствующие связи между сущностями.
На картинке — основные типы JOIN и визуальное представление того, какие строки попадут в результат выполнения запроса.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс
Опа, тут бывший сеньор одного из IT-отделов Яндекса Игорь Никитин выкатил целый канал про Python — и это лучшее, что есть в рунете по теме.
Качественные гайды. Советы от известных прогеров. Тематические мемасы. Короче, ничего лишнего.
Хватит душить питона, учись его кодить: /channel/+IzIPzvoa7p40ZTUy 🐍
✍️ PostgreSQL Wiki — справочник и документация по PostgreSQL!
На сайте опубликованы статьи, руководства, инструкции и практические материалы по работе с одной из самых популярных СУБД. Здесь можно найти информацию по установке, настройке, администрированию, оптимизации производительности, репликации, резервному копированию, расширениям и др.
📌 Оставляю ссылочку: wiki.postgresql.org
➡️ SQL Ready | #ресурс
Почему CONCAT_WS в PostgreSQL часто лучше обычной конкатенации строк!
Есть такие SQL-функции, которые вроде бы выглядят слишком простыми, чтобы о них писать отдельный пост. Но именно они часто убирают кучу мелких проблем в реальных проектах, CONCAT_WS — хороший пример.
Когда работаешь с тестовыми данными, кажется, что собрать строку очень просто. Есть имя, фамилия, отчество — соединяем их через пробел и получаем красивый результат.
Обычно первый вариант выглядит так:
SELECT
first_name || ' ' || middle_name || ' ' || last_name AS full_name
FROM users;
first_name = 'John'
middle_name = NULL
last_name = 'Smith'
John Smith
NULL
COALESCE:SELECT
first_name || ' ' ||
COALESCE(middle_name || ' ', '') ||
last_name
FROM users;
SELECT
CONCAT_WS(
' ',
first_name,
middle_name,
last_name
) AS full_name
FROM users;
CONCAT_WS расшифровывается как "concatenate with separator". Первый аргумент — разделитель, который нужно использовать между значениями.John + NULL + Smith
John Smith
Germany, Berlin, Alexanderplatz 10
CONCAT_WS пропускает NULL, но пустую строку считает настоящим значением.middle_name = ''
John Smith с двойным пробелом.NULLIF(middle_name, '')
CONCAT_WS уже работает предсказуемо. На небольших примерах это кажется мелочью. Но когда у тебя несколько миллионов записей и данные собираются из разных сервисов, именно такие детали начинают влиять на качество данных и количество лишнего кода.CONCAT_WS — хороший пример того, как правильный инструмент делает SQL проще. Если нужно собрать строку из нескольких необязательных полей — часто лучше использовать её, чем вручную обрабатывать каждый NULL.
Обычное сравнение через = и != ломается, как только появляется NULL!
old_value IS DISTINCT FROM new_value
NULL никогда не равен даже другому NULL, поэтому сравнение начинает вести себя не так, как ожидается.SELECT
NULL = NULL,
NULL != NULL;
TRUE и не FALSE, а NULL. Именно из-за этого часто ломается логика сравнения.SELECT *
FROM users
WHERE old_email != new_email;
NULL, строка может просто не попасть в выборку.SELECT *
FROM users
WHERE old_email IS DISTINCT FROM new_email;
NULL корректно участвует в сравнении. PostgreSQL считает NULL обычным сравниваемым состоянием.NULL IS DISTINCT FROM NULL -- false
NULL IS DISTINCT FROM 'test' -- true
'a' IS DISTINCT FROM 'b' -- true
NULL.
📂 Напоминалка по генерации уникальных ID в SQL и распределённых системах!
Например, Auto-Increment подходит для простых SQL-проектов, где одна база данных управляет последовательностью записей, а Snowflake/UUID чаще используют в высоконагруженных системах с микросервисами, где требуется генерация ID без единой точки отказа.
На картинке — 5 основных подходов к созданию уникальных идентификаторов.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс
DEFERRABLE constraints — проверяй связи в конце транзакции, а не после каждой строки!
Иногда данные нужно вставить в несколько связанных таблиц внутри одной транзакции, но порядок операций временно нарушает внешний ключ.
BEGIN;
INSERT INTO payments (id, order_id)
VALUES (1, 100);
INSERT INTO orders (id)
VALUES (100);
COMMIT;
FOREIGN KEY проверяется сразу, поэтому первый INSERT упадёт, если заказа 100 ещё нет.DEFERRABLE INITIALLY DEFERRED переносит проверку ограничения на момент COMMIT, поэтому база смотрит не на промежуточное состояние, а на итог транзакции.SET CONSTRAINTS ALL IMMEDIATE;
В PostgreSQL уникальность можно проверять не для всей таблицы, а только для части строк!
Допустим, у вас есть мягкое удаление пользователей:
SELECT email, deleted_at
FROM users;
CREATE UNIQUE INDEX users_email_uniq
ON users (email);
CREATE UNIQUE INDEX users_active_email_uniq
ON users (email)
WHERE deleted_at IS NULL;
CREATE UNIQUE INDEX one_draft_per_user
ON posts (user_id)
WHERE status = 'draft';
📂 Напоминалка по SQL Roadmap!
Например, сначала изучают основы SQL и работу с таблицами, затем переходят к JOIN, сложным запросам, подзапросам и оконным функциям, а дальше — к проектированию баз данных, транзакциям и оптимизации.
На картинке — путь изучения от базового уровня до продвинутого: основные команды, структура базы данных, работа с данными, производительность запросов и др.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс
0nix — Новая экосистема для профи.
Здесь не просто форум. Это готовая биржа, где заказчики находят исполнителей, а исполнители — живые деньги.
🛡Для кибербезопасников: Threat Intelligence, Осинтеров , Геоинтеров, Red Team, разработчиков инструментов. Ваша аудитория ждет ваши услуги.
💻 Для разработчиков и дизайнеров: Отдельные разделы с заказами на разработку, дизайн и графику. Портфолио — в топ!
Условия для первых участников: Минимальные комиссии на сделки, быстрый арбитраж и модерация.
Регистрируйся и забирай свою скидку на привилегии уже сегодня → 0nix.cc , 0nix.top
❤️🔥"Это разъ*бный сетап, бро!" 😤
Так сказал мой друг из Африки, когда увидел этот стол)
Не знаю уж че за сетап, меня зовут Саша и качественную необычную мебель из натурального дерева я делаю уже больше 12-ти лет, столько же занимаюсь и темой здоровья.
Когда я услышал, что до 10% смертности связано с сидячим образом жизни, меня это поразило и я задался целью делать максимально функциональные и полезные рабочие пространства, ибо геморрой в 30 это конечно довольно нишево, но все же сомнительно 😂
Ну а собрать такой комплект под свои задачи и при этом сразу прикинуть цены вы можете в удобном Mini App конструкторе ➕
⚡️ Айтишник из «VISION» скупил курсы айти школ и выложил гигабайты материалов к себе
Каждый найдет что-то по душе:
1202 ГБ — Python
1811 ГБ — Frontend
1100 ГБ — C / C++ / C#
804 ГБ — Java
411 ГБ — SQL & БД
309 ГБ — DevOps
998 ГБ — ИБ & Хакинг
773 ГБ — Kotlin / Swift
189 ГБ — PHP
201 ГБ — GoLang
170 ГБ — Rust
167 ГБ — QA / Тестирование
310 ГБ — 1C + Лицензии
495 ГБ — Машинное обучение
704 ГБ — Аналитика Данных
991 ГБ — Дизайн
Материалы в закрепе, постоянно пополняются👆🏻
📂 Напоминалка по выбору NoSQL баз данных для проектов!
Например, MongoDB подходит для работы с гибкими документными структурами, Redis — для высокопроизводительного кэширования и хранения данных в памяти, а Cassandra — для распределённых систем с огромными объёмами данных и высокой доступностью.
На картинке — сравнение популярных NoSQL решений, их особенностей и основных сценариев использования: от поиска и аналитики до IoT, социальных сетей, e-commerce и real-time приложений.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс
🖥 Разберем ALTER — команда для изменения структуры таблиц!Добавить колонку, переименовать её, изменить тип или задать ограничение — всё это делается через ALTER TABLE. Один из важнейших инструментов в работе с готовыми таблицами.
➡️ SQL Ready | #шпора
🐱 Полезную статью нашёл на Хабре: «PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря»!
В этой статье:• Рассматриваются возможности PostgreSQL, которые помогают решать типовые backend-задачи на уровне базы;• Разбираются эффективные инструменты для работы с очередями, запросами, индексами и поиском;• Показывается, как использовать встроенные механизмы PostgreSQL для повышения производительности приложений.
🔊 Продолжайте читать на Habr!
➡️ SQL Ready | #статья
Почему ROW_NUMBER(), RANK() и DENSE_RANK() в SQL дают разный результат!
Есть такие оконные функции в SQL, которые выглядят почти одинаково, но используются для разных задач. ROW_NUMBER(), RANK() и DENSE_RANK() все умеют добавлять номера к строкам, но поведение меняется, когда в данных появляются одинаковые значения.
На тестовых данных разница может быть незаметной. Но в реальных задачах это влияет на рейтинги пользователей, отчёты, аналитику и любые запросы, где важно правильное место записи.
Например, есть таблица с результатами:
score
-----
100
100
90
80
ROW_NUMBER():SELECT
score,
ROW_NUMBER() OVER (
ORDER BY score DESC
) AS position
FROM results;
score | position
------+---------
100 | 1
100 | 2
90 | 3
80 | 4
ROW_NUMBER() всегда выдаёт уникальный номер для каждой строки. Даже если два значения одинаковые, они всё равно получат разные позиции.RANK():SELECT
score,
RANK() OVER (
ORDER BY score DESC
) AS position
FROM results;
score | position
------+---------
100 | 1
100 | 1
90 | 3
80 | 4
RANK() учитывает одинаковые значения и присваивает им одинаковый номер. Но после одинаковых результатов появляются пропуски. В примере выше два участника заняли первое место, поэтому следующий результат получает третье место.DENSE_RANK():SELECT
score,
DENSE_RANK() OVER (
ORDER BY score DESC
) AS position
FROM results;
score | position
------+---------
100 | 1
100 | 1
90 | 2
80 | 3
DENSE_RANK() работает похоже на RANK(), но продолжает нумерацию без пропусков. Получается простое правило: ROW_NUMBER() — когда каждая строка должна получить свой уникальный номер; RANK() — когда одинаковые значения должны иметь одинаковое место, а пропуски после них допустимы; DENSE_RANK() — когда одинаковые значения должны иметь одинаковое место, но нумерация должна идти без пропусков.ROW_NUMBER(). Если несколько строк имеют одинаковое значение для сортировки:SELECT
id,
score,
ROW_NUMBER() OVER (
ORDER BY score DESC
) AS position
FROM results;
SELECT
id,
score,
ROW_NUMBER() OVER (
ORDER BY score DESC, id
) AS position
FROM results;
ROW_NUMBER(), RANK() и DENSE_RANK() решают похожую задачу, но предназначены для разных сценариев. Главное — понимать, нужна ли вам обычная нумерация строк или именно логика рейтинга.
🤔 Learn PostgreSQL — информативное руководство!
Этот репозиторий поможет разобраться с PostgreSQL с нуля и понять, как работать с базой данных на практике. Здесь простым языком объясняются SQL-запросы, создание таблиц, связи между ними, индексы, объединения, агрегатные функции и др. Материал построен последовательно и с большим количеством примеров.
Оставляю ссылочку: GitHub 📱
Используй RETURNING как временную таблицу!
Многие после UPDATE делают отдельный SELECT, чтобы получить изменённые данные.
Но PostgreSQL уже умеет вернуть результат изменения через RETURNING.
UPDATE orders
SET status = 'paid',
paid_at = now()
WHERE id = 1001
RETURNING id, status, paid_at;
RETURNING можно сразу передавать дальше.WITH changed AS (
UPDATE orders
SET status = 'cancelled'
WHERE id = 1001
RETURNING id, status
)
INSERT INTO order_history(order_id, new_status)
SELECT id, status
FROM changed;
WITH moved AS (
DELETE FROM queue
WHERE id = 55
RETURNING *
)
INSERT INTO archive_queue
SELECT *
FROM moved;
📂 Напоминалка по шардингу данных!
Например, range-based шардинг делит данные по диапазонам значений, hash-based — распределяет записи через хэш-функцию, а consistent hashing помогает минимизировать перераспределение данных при добавлении новых нод.
На картинке — 4 алгоритма шардинга, которые полезно знать при проектировании масштабируемых систем и высоконагруженных баз данных.
Сохрани, чтобы не потерять!
➡️ SQL Ready | #ресурс
IT мероприятия 🤘
Всё самое интересное для карьеры в IT: митапы, хакатоны, конференции, стажировки и обучение.
Подписывайся 🤘
1. Москва
2. Санкт-Петербург
3. Для стажеров и студентов
👍 Годная статья вышла на Хабре: «Шардированный не значит распределённый, что важно знать, когда PostgreSQL становится мало»!
В этой статье:• Объясняется разница между шардированным PostgreSQL и настоящими распределёнными СУБД;
• Разбирается, почему Citus и похожие решения не дают полноценные ACID-гарантии для multi-shard транзакций;
• Показывается, как работают 2PC, distributed snapshot и уровни изоляции транзакций;
• На примерах объясняются проблемы consistency и eventual consistency в распределённых системах;
🔊 Продолжай читать на Habr!
🐱 PostgreSQL Cheat Sheet — удобная шпаргалка по PostgreSQL!
Этот репозиторий собрал самые важные команды и конструкции PostgreSQL в одном месте. Здесь можно быстро вспомнить синтаксис запросов, работу с таблицами, индексами, представлениями, функциями, транзакциями и др. Такая шпаргалка особенно полезна во время работы или подготовки к собеседованию.
Оставляю ссылочку: GitHub 📱
😒 Официальная библиотека промптов для Claude от Anthropic
Разработчики из Anthropic обновили и структурировали масштабный хаб готовых запросов для своей языковой модели. База создана для того, чтобы пользователи могли выжать максимум из Claude при решении прикладных и технических задач, не тратя время на самостоятельный подбор формулировок.
⚡️Внутри собраны сотни шаблонов под самые разные сценарии:
🟦Для безопасности: готовые конструкции для проверки кода на уязвимости и анализа граничных условий работы алгоритмов.
🟦Для разработчиков: шаблоны для глубокого ревью кода, автоматического поиска багов, рефакторинга, написания юнит-тестов и проектирования архитектуры.
🟦Для автоматизации и менеджмента: промпты под стратегическое планирование, парсинг неструктурированных данных, генерацию технической документации и выстраивание логики для ИИ-агентов.
🟦Разберетесь, как работают кибератаки и как грамотно защитить свои данные.
🟦Познакомитесь с направлениями и профессиями в кибербезопасности, чтобы выбрать свой трек.
🟦Получите скидку, если решите продолжить обучение в CyberYozh Academy.
Почему оконные функции могут давать неверный результат из-за RANGE вместо ROWS!
Одна из самых неприятных особенностей window functions — frame по умолчанию. Запрос выглядит корректно, проходит проверку глазами, но накопительная сумма может считаться совсем не так, как ожидает разработчик.
Особенно часто это встречается там, где важен порядок операций: расчёт балансов, транзакции, аналитика событий и любые накопительные показатели.
Есть таблица:
payments(id, created_at, amount)
SELECT
id,
created_at,
amount,
SUM(amount) OVER (
ORDER BY created_at
) AS running_total
FROM payments;
ORDER BY не указать его явно, SQL использует значение по умолчанию:RANGE BETWEEN UNBOUNDED PRECEDING
AND CURRENT ROW
RANGE работает не по физическому положению строк, а по значениям сортировки. То есть база смотрит на поле из ORDER BY и объединяет строки с одинаковым значением в одну логическую группу.id=1, created_at='2026-01-01 10:00:00', amount=100
id=2, created_at='2026-01-01 10:00:00', amount=200
id=3, created_at='2026-01-01 11:00:00', amount=300
RANGE они являются одной группой, потому что значение сортировки совпадает.SUM(amount) OVER (
ORDER BY created_at
)
300
300
600
RANGE уже включает обе записи с одинаковым created_at. Получается: 100 + 200 = 300. Поэтому первая строка сразу показывает итог двух операций. Это не ошибка SQL, это стандартное поведение RANGE.ROWS, который работает именно с физическими строками окна.SELECT
id,
created_at,
amount,
SUM(amount) OVER (
ORDER BY created_at, id
ROWS BETWEEN UNBOUNDED PRECEDING
AND CURRENT ROW
) AS running_total
FROM payments;
100
300
600
ROWS, одного created_at может быть недостаточно.id=1, created_at='10:00:00', amount=100
id=2, created_at='10:00:00', amount=200
ORDER BY created_at, id
RANGEROWS нужен, когда важен порядок конкретных строк. Для обычного running total почти всегда стоит явно указывать ROWS.cumulative sum показывает одинаковые значения на нескольких строках подряд — проверьте ORDER BY и frame окна. Чаще всего причина в том, что ожидали ROWS, а получили поведение RANGE.
Разбираем почему ORDER BY RANDOM() на больших таблицах не лучшая идея!
Если нужно вытащить случайные строки из таблицы, многие пишут так, например в PostgreSQL:
SELECT *
FROM products
ORDER BY RANDOM()
LIMIT 10;
LIMIT.SELECT *
FROM products
ORDER BY RANDOM()
LIMIT 1;
SELECT *
FROM products
WHERE id >= 1 + FLOOR(RANDOM() * (SELECT MAX(id) FROM products))::int
ORDER BY id
LIMIT 1;
id
1
2
3
10000
10001
OFFSET:SELECT *
FROM products
OFFSET FLOOR(RANDOM() * (SELECT COUNT(*) FROM products))::int
LIMIT 1;
OFFSET тоже есть проблема: чем больше offset, тем больше строк базе придётся пропустить. Плюс в PostgreSQL COUNT(*) на большой таблице тоже может быть дорогой операцией.TABLESAMPLE:SELECT *
FROM products TABLESAMPLE SYSTEM (1);
SELECT *
FROM products TABLESAMPLE BERNOULLI (1);
TABLESAMPLE выбирает примерный процент таблицы, а не конкретное количество строк.LIMIT:SELECT *
FROM products TABLESAMPLE SYSTEM (1)
LIMIT 10;
SYSTEM работает быстрее, но выбирает данные блоками, поэтому распределение менее равномерное. BERNOULLI ближе к построчной случайной выборке, но обычно дороже. В общем, мысль простая:ORDER BY RANDOM()
Разбор JSON в строки на стороне PostgreSQL!
Когда из API прилетает массив объектов, не обязательно разбирать его в коде и делать много отдельных INSERT или UPDATE. PostgreSQL умеет превратить JSON-массив в обычную табличную выборку.
SELECT *
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric);
JSON вида [{"id":1,"amount":500},{"id":2,"amount":900}], а на выходе получить нормальные типизированные строки.INSERT INTO payments (id, amount)
SELECT id, amount
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric);
UPDATE payments p
SET amount = x.amount
FROM jsonb_to_recordset($1::jsonb)
AS x(id bigint, amount numeric)
WHERE p.id = x.id;
👍 ClickHouse + PostgreSQL — интеграция OLTP и OLAP для аналитики!
На странице собрана официальная документация ClickHouse по работе с PostgreSQL. Здесь подробно разбираются импорт данных, репликация таблиц, синхронизация и выполнение запросов к PostgreSQL напрямую из ClickHouse. Также есть примеры настройки и практические сценарии использования.
📌 Оставляю ссылочку: clickhouse.com
➡️ SQL Ready | #ресурс