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

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 на больших таблицах.

🖥 Гайд по продвинутому профессиональному использованию 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'

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

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

🖥 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 вернется только самое последнее событие

🖥 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

🔥 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 - библиотека МЛ и ИИ книг

📘 Как 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 инъекции

источник

🖥 Новый курс на Stepik - PostgreSQL для разработчиков: от основ к созданию API

Здесь на пальцах объясняют не только как писать SQL-запросы, а строить настоящие backend-сервисы с базой данных как у профи.

В этом курсе ты шаг за шагом создашь REST API на FastAPI + PostgreSQL:
от установки среды и первых таблиц - до масштабируемого приложения с безопасностью и CRUD-операциями.

🔹 На практике разберете:
• SQL-запросы, фильтры, агрегаты и подзапросы
• Связи между таблицами и нормализацию БД
• Взаимодействие Python и PostgreSQL
• Реализацию REST API и подключение базы
• Оптимизацию и разбор реальных задач с собеседований

⚡ После курса у вас будет свой работающий API-проект и реальные навыки работы с PostgreSQL в продакшене.

🎁 Сегодня дарим промокод –30% от цены: SQLISGREAT

🚀 Прокачаю свои знания: https://stepik.org/course/255542/

🖥 Полный гайд: защита от SQL-инъекций для разработчиков

SQL-инъекции остаются одной из самых частых и опасных уязвимостей в веб-приложениях. Ошибка в одном запросе — и злоумышленник получает доступ к базе данных, паролям и пользовательским данным.

В этом материале — полный практический разбор:
как именно происходят SQL-инъекции, какие ошибки разработчиков к ним приводят, как их распознать в коде и главное — как защититься.

Разберём реальные примеры на Python, PHP и Go, посмотрим, как атакующий «взламывает» запрос, и научимся писать безопасный код с параметризованными запросами и ORM.

Это не теория, а руководство, которое поможет понять уязвимость изнутри и навсегда закрыть её в своих проектах.

👉 Читать гайд

Как переписать и оптимизировать ваши SQL-запросы к Pandas на пяти простых примерах

Аналитики данных, инженеры и учёные одинаково знакомы с SQL. Язык запросов по-прежнему широко используется для работы с реляционными базами данных любого типа.

Однако, в настоящее время, всё больше и больше, особенно для аналитиков данных, растут технические требования, и ожидается, что люди, по крайней мере, знают основы языка программирования. При работе с данными Python и Pandas являются обычным дополнением к списку требований в описании вакансий.

Хотя Pandas может быть новым для людей, знакомых с SQL, концепции выбора, фильтрации и агрегирования данных в SQL легко переносятся в Pandas. Давайте рассмотрим в этой статье некоторые распространённые SQL-запросы и способы их написания и оптимизации в Pandas.

Читать

🖥 Гайд по PostgreSQL для продвинутых разработчиков

PostgreSQL – одна из самых мощных СУБД с открытым исходным кодом. Этот гайд подробно охватывает ключевые аспекты PostgreSQL: от внутренней архитектуры до приёмов оптимизации. Мы рассмотрим администрирование, производительность, расширения, инструменты, а также сравним популярные ORM для Python и Go. В конце приведён список продвинутых вопросов, часто встречающихся на собеседованиях.

🟠Гайд