Библиотека баз данных

🖥 SQL-квест: фэнтезийное приключение для аналитиков данных Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах. 🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮 В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты. Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест. 🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/

SQL хитрый совет для про 💡 Используй COUNT(*) FILTER вместо CASE WHEN — быстрее, чище и читаемее. ❌ Как делают обычно:

SELECT
  COUNT(CASE WHEN status = 'success' THEN 1 END) AS success_cnt,
  COUNT(CASE WHEN status = 'error' THEN 1 END)   AS error_cnt
FROM events;

✅ Как делают профи:

Копировать код
SELECT
  COUNT(*) FILTER (WHERE status = 'success') AS success_cnt,
  COUNT(*) FILTER (WHERE status = 'error')   AS error_cnt
FROM events;

Почему это важно: - меньше вычислений внутри агрегаций - оптимизатору проще строить план - код короче и легче поддерживать - особенно эффективно в аналитических запросах Где работает: - PostgreSQL - SQLite (частично) - DuckDB - ClickHouse (через аналоги) Мелочь, но именно из таких мелочей складывается SQL уровня senior.

Чем больше компания, тем больше вызовов 😱 Был десяток команд разработки – теперь их сотни. Единицы развертываний в день превращаются в тысячи. Как в этом потоке сохранить контроль, прозрачность и управляемость? Как можно автоматизировать рутинные процессы? Разрозненные инструменты и отсутствие единой картины тормозят скорость и снижают качество доставки – что делать? 🎯Если у вас нет ответа на эти вопросы, вашей компании стоит внедрить IT-решение, которое станет "единым источником правды". Оно автоматизирует учет IT-компонентов, управление стендами и планирование поставок, сокращая время на рутину и повышая надежность процессов. Название такого решения – Digital Q.CMDB. Диасофт посвятит этому решению вебинар, который состоится 23 декабря в 14:00 🗓 Эксперты познакомят вас с решением, расскажут про вызовы масштабирования и затронут практику: от бизнес-требований до поставки. Welcome: регистрируйтесь по ссылке! Реклама. ООО "ДИАСОФТ ЭКОСИСТЕМА". ИНН 9715403607.

SQL-совет 💡 Если в запросе используется IN (subquery) - почти всегда выгоднее заменить его на EXISTS. ❌ Часто медленно:

SELECT *
FROM orders o
WHERE o.user_id IN (
  SELECT u.id FROM users u WHERE u.country = 'US'
);

✅ Обычно быстрее и безопаснее:

SELECT *
FROM orders o
WHERE EXISTS (
  SELECT 1
  FROM users u
  WHERE u.id = o.user_id
    AND u.country = 'US'
);

Почему это важно: - IN может материализовать подзапрос целиком - EXISTS работает как semi-join и рано останавливается - Лучше масштабируется на больших данных - Меньше сюрпризов с NULL Особенно критично в PostgreSQL, MySQL и Oracle на больших таблицах.

В условиях повышенных требований к отказоустойчивости и импортозамещению инфраструктуры вопросы бесперебойной работы систем управления базами данных (СУБД) выходят на первый план ⚡️ Но как не потерять базу данных и обеспечить высокую доступность – в том числе на импортозамещенном ПО? Для этого есть решение, которое обеспечивает комплексную настройку и оптимизацию IT- инфраструктуры (серверы, виртуализация, ОС, СУБД и др.) под прикладные системы, чтобы обеспечить им высокую производительность, отказоустойчивость и стабильную работу, в том числе на импортонезависимом стеке, — и это Digital Q.SystemIntegration 🎯 Ему посвящен вебинар, который пройдет 18 декабря в 14:00! Эксперты Диасофт также разберут: ▪️практические подходы к построению высокодоступных кластеров на базе PostgreSQL и его форков. ▪️реальные кейсы и проблемы (VACUUM, влияние горизонта транзакций) + их решения. Регистрируйтесь по ссылке! Реклама. ООО "ДИАСОФТ". ИНН 7715560268.

🖥 Гайд по продвинутому профессиональному использованию SQL В этом руководстве мы рассмотрим ключевые аспекты работы с SQL на практике. Начнём с сравнения популярных СУБД, затем перейдём к продвинутым приёмам аналитического SQL, оптимизации запросов, администрированию баз данных, и закончится всё интеграцией SQL с Python (SQLAlchemy, pandas и т.д.). Для каждого раздела приведены примеры на реальных сценариях (интернет-магазин, CRM, аналитика продаж), код и полезные советы. 👉 Читать гайд

🔥 На stepik вышел курс, который учит Создавать настоящие AI-сервисы, а не просто запускать скрипты? Этот практический курс по Python и FastAPI покажет, как собрать полноценное приложение с ИИ, базой данных, автогенерацией контента и Telegram-ботом. Ты пройдёшь путь от первого HTTP-запроса до рабочего сервиса, который сам генерирует текст через ИИ, сохраняет данные, отправляет результаты по расписанию и отвечает пользователям. Никакой теории ради теории - только практические шаги, из которых рождается реальный продукт. 🎁 48 часов действует скидка в 40% процентов 👉 Начать учиться на Stepik

🚀 Новый продвинутый планировщик заданий для PostgreSQL - лучше, чем cron Если устал от cron и временных триггеров, обрати внимание на pg_timetable: ✅ Сильный: гибкий, надёжный, с богатым функционалом ✅ Легко настраивается, понятен и прозрачен ✅ Позволяет: • запускать SQL-задачи по расписанию • отслеживать их статус и history • обеспечивать graceful restart и защиту от сбоев Идеален для рабочих баз, сложной логики задач и критичных приложений. 📦 Репозиторий: https://github.com/cybertec-postgresql/pg_timetable #golang #postgresql #devops #golang

🚀 SQL-совет: Используйте computed (вычисляемые) колонки и индексы по ним, когда ваши запросы постоянно фильтруют или сортируют по функции.

Плохо:
WHERE LOWER(email) = 'user@mail.com'

Это ломает индекс — оптимизатор не может его использовать.

Лучше:
ALTER TABLE users 
ADD email_lower AS LOWER(email) STORED;

CREATE INDEX idx_users_email_lower ON users(email_lower);

Теперь:
WHERE email_lower = 'user@mail.com'

Запросы становятся мгновенно быстрее, а индекс используется эффективно. Очень немногие разработчики знают и применяют этот трюк, но он спасает производительность на реальных системах.

Полиглот – человек, знающий много языков 😛 IT-полиглот – функциональность для ускоренного перехода с Oracle и MS SQL 🤖 Но обо всем по порядку: Основная сложность перехода на российскую СУБД — не поиск аналога, а обеспечение комплексного перехода с единой ответственностью, гарантиями регуляторов и прозрачной экономикой проекта. Digital Q.DataBase от Диасофт решает эту задачу кардинально. Система обеспечивает переход с зарубежных СУБД без переписывания кода приложений. Новая функциональность "Полиглот" в Digital Q.DataBase обеспечивает непосредственное исполнение запросов, написанных на диалектах SQL ведущих зарубежных СУБД: Oracle (PL/SQL), Microsoft SQL Server (T-SQL), а также PostgreSQL (PL/pgSQL). 🆓 Диасофт запустил бесплатную версию СУБД Digital Q.DataBase. Решение подходит для всех категорий пользователей, включая коммерческие организации и госучреждения. Скачивайте дистрибутив бесплатно на сайте! Реклама. ООО "ДИАСОФТ ЭКОСИСТЕМА". ИНН 9715403607.

🖥 SQL СОВЕТ Когда нужно взять по одному самому свежему событию на пользователя, не делай вложенные подзапросы с MAX и лишние JOIN, используй оконную функцию ROW_NUMBER по разделу и упорядочиванию, так запрос будет понятнее и часто быстрее на реальных данных.

SELECT *
FROM (
    SELECT
        user_id,
        event_type,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM events
) t
WHERE rn = 1;

-- Для каждого user_id вернется только самое последнее событие

Производительные или и выгодные базы данных в облаке Безопасные, масштабируемые и отказоустойчивые базы данных — одна из ключевых потребностей любого проекта. Именно такие предлагает Selectel. СУБД под разные запросы: от универсальной PostgreSQL до поисковой и аналитической БД Opensearch Новые клиенты сейчас могут получить до 30 000 бонусов на использование облачных баз данных Selectel. Провайдер гарантирует: 🔹Высокую производительность. Выбирайте оптимальную конфигурацию кластера на базе мощного железа и локальных NVMe-дисков. 🔹Надежность. Автоматические бесплатные бэкапы с восстановлением вплоть до секунды — на стороне Selectel. А создать отказоустойчивый кластер можно всего от двух нод и сэкономить до 33%. 🔹Гибкое масштабирование. При росте нагрузки можно поменять конфигурацию облачного сервера и количество реплик без простоя. Успейте зарегистрироваться и оставить заявку на участие в акции, чтобы протестировать сервис бесплатно: https://slc.tl/y7zta Реклама. АО "Селектел". erid:2W5zFH92NVE

🖥 SQL большой гайд. Как правильно выбрать ORM Эта статья - не про «как написать SELECT, а про настоящую инженерную работу: принципы нормализации, дизайн схем, практики оптимизации SQL, работа с транзакциями, и главное - как выбрать и использовать ORM так, чтобы он помогал, а не мешал. Если тебе нужен инструмент, который выдержит рост проекта и не взорвётся через год, здесь ты найдёшь системный подход, проверенные шаблоны и практические примеры, которым уже доверяют зрелые инженерные команды. Готовы? Тогда начинаем строить архитектуру, которую не стыдно масштабировать. https://uproger.com/sql-bolshoj-gajd-kak-pravilno-vybrat-orm/

🚨 SQL Никогда НЕ ДЕЛАЙ ТАК #sql НИКОГДА НЕ ЛОМАЙ ИНДЕКСЫ ФУНКЦИЯМИ: не оборачивай индексируемые поля в функции внутри WHERE. Как только ты пишешь LOWER(), CAST(), COALESCE() или любые вычисления по колонке — индекс перестаёт работать, и запрос падает в полное сканирование таблицы. Это одна из самых тихих причин, почему запросы внезапно превращаются в тормоза. Вместо этого приводи значения заранее или используй функциональные индексы.

 Плохо: индекс по email НЕ используется  
SELECT *  
FROM users  
WHERE LOWER(email) = 'user@example.com';

-- Хорошо: нормализуем значение заранее  
SELECT *  
FROM users  
WHERE email = 'user@example.com';

-- Или создаём функциональный индекс (PostgreSQL)  
CREATE INDEX idx_users_email_lower ON users (LOWER(email));

https://www.youtube.com/shorts/AyiAslOeJFA

🔄 Миграция на российскую СУБД без переписывания кода 25 ноября в 14:00 (МСК) — вебинар о переходе с MS SQL или Oracle на Digital Q.DataBase с минимальными издержками. 💡 На вебинаре узнаете: 1️⃣ Как Digital Q.DataBase объединила три диалекта — T-SQL, PL/SQL и PL/pgSQL. 2️⃣ Как мигрировать ПО с любой СУБД без переписывания кода. 3️⃣ Что входит в поставку (включая то, что другие вендоры лицензируют отдельно). 4️⃣ Как получить бесплатную версию Digital Q.DataBase. 🏆 Digital Q.DataBase: — Сертификация ФСТЭК 4-го уровня — 1 место в рейтинге CNews Market «Конвергентные СУБД» 👥 Для кого: Разработчики, администраторы БД, CIO, CDTO, руководители проектов импортозамещения. 🎤 Спикер: Андрей Жуйков, руководитель направления 📅 25 ноября | 🕐 14:00 (МСК) | 💻 Онлайн, бесплатно 👉 Регистрация #реклама О рекламодателе

🔥 Hugging Face снова выкатили полезные материалы. Вышел бесплатный плейбук о том, как изнутри строят SOTA-модели. Без общих слов - только реальные решения и нюансы, которые обычно скрыты внутри исследовательских команд. Это полноценный мастеркласс на 214 страниц для тех, кто хочет понимать, как устроены современные LLM. Что внутри: • Логика построения модели: зачем → что → как • Как разработчики берут модель и по частям включают/выключают компоненты (или меняют их) • Архитектура: ключевые выборы и trade-offs • Искусство подбора и очистки данных • Как проходит обучение моделей • Пост-тренинг и RLHF в 2025 • Инфраструктура больших моделей По первым страницам - уровень деталей как в Ultra-scale playbook. Ссылка: https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#designing-the-model-architecture Видео: https://www.youtube.com/watch?v=LGzO-Mn0DJQ #AI #LLM #MachineLearning #HuggingFace @sql_lib - библиотека МЛ и ИИ книг

Не пропустите! 27 октября в 20:00 пройдет бесплатный урок по теме “PostgreSQL для администраторов и разработчиков” по теме “Ликбез по типам данных в PostgreSQL”. Запись: https://otus.pw/H7P6/ Насколько хорошо вы знаете типы данных? Понимаете ли, как устроены "под капотом" отрицательные числа, и на что это влияет? Можете ли осознанно рассказать, почему нельзя хранить деньги как float или сколько байт занимает эмодзи "Семья"?  Дмитрий Кириллов на своём авторском вебинаре раскроет секреты типов данных в PostgreSQL на простых и наглядных примерах.  В результате вебинара:  - Вы узнаете теоретические основы типов данных  - научитесь осознанно выбирать конкретный тип под задачу  - освоите полезные практические приёмы Записывайтесь на вебинар и получит спец. предложение на обучение:  https://otus.pw/H7P6/?erid=2W5zFGrwG9v Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

📘 Как PostgreSQL научился масштабироваться без боли Менеджер буферов в PostgreSQL отвечает за кэширование 8KB-страниц диска в общей памяти фиксированного размера. Для поиска используется хеш-таблица (через BufferTag → buffer ID), а для удаления страниц — clock-sweep алгоритм. Первые версии были предельно простыми — с глобальной блокировкой, что быстро приводило к узким местам под нагрузкой. За 30 лет система эволюционировала: от единой глобальной блокировки к блокировкам на каждый буфер и партицию и, наконец, к атомарным операциям, обеспечивающим почти lock-free доступ к структурам памяти. Это позволило резко снизить конфликтность и повысить масштабируемость в OLTP-нагрузках, сохранив устойчивость при работе с общей памятью. Философия дизайна PostgreSQL — минимальное время удержания блокировок, абстракция аппаратных различий через атомики и постоянная оптимизация реальных узких мест по результатам профилирования. Отличный блог-пост с хронологией ключевых вех и ссылками на важные коммиты за эти годы — по ссылке 👇 Подробности

🖥 SQL за полтора часа в одном видео! Полный базовый курс по SQL. Базы данных курс для начинающих! 00:00:00 Введение 00:02:43 Платные курсы и что изучать дальше 00:04:55 Коротко об онлайн редакторе 00:07:11 Что такое база данных 00:08:10 Что такое CRUD 00:10:05 Запрос на создание первой таблицы 00:11:57 Типы данных у атрибутов(колонок) (DATA TYPES) 00:17:26 Прописываем атрибуты(колонки) первой таблицы 00:21:07 Создаем первую таблицу (CREATE TABLE) 00:21:38 Проверка на наличие таблицы при создании (IF NOT EXISTS) 00:22:18 Запрос на удаление таблицы(DROP TABLE) 00:22:33 Проверка на наличие таблицы при удалении(IF EXISTS) 00:22:57 Запрос на добавление объекта в таблицу (INSER INTO table) 00:23:35 Запрос на чтение(получение) объектов из таблицы(SELECT * FROM table) 00:24:18 Модификаторы для атрибутов(колонок) таблицы(NOT NULL, DEFAULT, UNIQUE) 00:29:26 Изменение уже существующей таблицы(ALTER TABLE, ADD, DROP, RENAME, MODIFY COLUMN) 00:36:08 Удаление объектов из таблицы(DELETE FROM table) 00:37:06 Редактирование объекта в таблице(UPDATE table) 00:39:03 Первичный ключ(PRIMARY KEY) 00:45:37 Композиция в бд 00:50:38 "Иностранный" ключ(FOREIGN KEY) 00:57:26 Индексы в бд(INDEX) 00:59:24 Готовим данные для темы алиас, юнион и слияние таблиц 01:03:30 Слияние таблиц(INNER JOIN) 01:06:02 Слияние таблиц(LEFT JOIN) 01:06:53 Слияние таблиц(RIGHT JOIN) 01:07:26 Слияние таблиц(FULL JOIN/OUTER JOIN) и Union 01:09:04 Алиас(table AS alias) 01:12:18 Select Distinct в SQL 01:13:42 AND OR NOT в SQL 01:16:18 ORDER BY и LIMIT в SQL 01:17:35 MIN и MAX в SQL 01:18:25 COUNT SUM AVG в SQL 01:19:29 LIKE в SQL 01:21:31 IN и BETWEEN в SQL 01:22:50 GROUP BY в SQL 01:25:17 EXISTS в SQL 01:27:37 ANY и SOME в SQL 01:29:00 INSERT INTO в SQL 01:30:40 Отношения в базе данных 01:32:11 Отношения один к одному 01:33:09 Отношения один ко многим 01:34:09 Отношения многие ко многим 01:37:10 Отношения один к одному и один ко многим "через" 01:39:10 SQL инъекции источник