Вопрос по SQL:

Какой результат вернёт этот запрос?

Посмотрим, кто хорошо знает агрегатные функции.

Объясни свой ответ.

👉 @SQLPortal

Появилась интересная новинка для тех, кто постоянно работает с данными и устал писать SQL вручную. Вышел OpenChatBI — опенсорсный BI инструмент, который позволяет делать запросы к базе обычным языком и получать результат в виде таблиц или графиков.

Инструмент построен на LangGraph и LangChain, умеет превращать текстовые запросы в SQL и автоматически их выполнять. Для сложных вопросов можно подключить внешние источники знаний или расширить функциональность через MCP.

У OpenChatBI есть удобный Web UI, а установка занимает пару минут — достаточно поставить через pip или uv, подключить базу и настроить LLM.

Репозиторий здесь: https://github.com/zhongyu09/openchatbi

👉 @SQLPortal

Типичные проблемы при очистке данных в SQL и как их решать

Удаление дубликатов
├── Использование DISTINCT
└── Использование ROW_NUMBER()

Обработка пропущенных значений
├── Фильтрация NULL
└── Замена NULL

Стандартизация данных
├── Приведение типов
└── Форматирование данных

Удаление выбросов
├── Фильтрация по условиям
└── Применение статистических методов

Исправление опечаток
├── Использование UPDATE
└── Использование CASE

Нормализация данных
├── Создание lookup-таблиц
└── Разделение колонок

Обработка разнородных данных
├── Использование CASE WHEN
└── Использование REPLACE

Парсинг данных
├── Использование SUBSTRING
└── Использование CHARINDEX

👉 @SQLPortal

Мои топ-5 советов по оптимизации Postgres для разработчиков:

- научись пользоваться EXPLAIN. Он покажет, как именно выполняется запрос и где его можно подтюнить.

- понимай, когда нужны индексы. Смотри пункт выше, чтобы убедиться, что индекс реально решает проблему. Не переборщи с индексами, но и не забивай на них.

- используй connection pooling. В Postgres его нет из коробки, и для каждого подключения поднимается отдельный процесс. Используй серверный или клиентский пул, а лучше оба. Просто используй что-то.

- запрашивай только то, что надо. Избегай SELECT * FROM. Будь точнее SELECT column1, column2 FROM. Не трать ресурсы на данные, которые твоему приложению не нужны.

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

👉 @SQLPortal

В Postgres есть функция age(), которая позволяет быстро получить возраст по timestamp.

👉 @SQLPortal

В PL/SQL

EXCEPTION WHEN OTHERS THEN

Ловит любые ошибки

Если пихать это везде и не пробрасывать ошибку дальше, можно спокойно пропустить неожиданные проблемы

Поэтому компилятор кидает предупреждение PLW-6009

Если в кастомном логгере ты все-таки пробрасываешь ошибку дальше, то используй

PRAGMA SUPPRESSES_WARNING_6009

чтобы отключить это предупреждение

ALTER SESSION SET PLSQL_WARNINGS='ENABLE:(6009)';

CREATE PROCEDURE logging ( err VARCHAR2 ) AS
    PRAGMA SUPPRESSES_WARNING_6009(logging);
BEGIN
    -- логирование ошибки / повторный RAISE
END;
/

CREATE PROCEDURE do_stuff AS
BEGIN
    -- какая-то логика
EXCEPTION
    WHEN OTHERS THEN logging('Error details');
END;
/

-- Нет ошибок.

👉 @SQLPortal

В Postgres есть десятки типов индексов, заточенных под разные типы данных и задачи. В целом их можно разделить на две категории:

По назначению или области применения (что именно индексируем). Здесь мы решаем, какие колонки или данные таблицы индексировать и нужно ли применять функцию к индексируемым значениям. Примеры: индекс по одной колонке, составной (composite), покрывающий (covering), частичный (partial) и функциональный/выражения (functional/expression) индекс.

По внутренней структуре и методу доступа (как индексируем). Эта категория основана на том, как индекс хранит данные под капотом и как СУБД к ним обращается. Примеры: B-tree, hash, GIN, RUM, GiST, SP-GiST, BRIN, HNSW и IVFFlat.

Когда ты выполняешь CREATE INDEX, ты всегда выбираешь тип индекса из первой категории (что индексировать). Выбор структуры (как индексировать) — опционален. Если ничего не указать, Postgres по умолчанию использует B-tree.

👉 @SQLPortal

Postgres UNION vs UNION ALL

Оба оператора объединяют результаты двух или более SELECT запросов в один набор данных.

UNION удаляет дубликаты

UNION ALL оставляет дубликаты

Если ты уверен что дубликатов нет или они тебя не волнуют, UNION ALL будет быстрее, потому что пропускает проверку на повторяющиеся строки.

👉 @SQLPortal

Мы уже знаем причину худшего сбоя Cloudflare с 2019 года — криво спроектированный SQL-запрос.

После изменения прав он начал дублировать данные.

Внутренний файл разросся до безумных размеров, уронил тысячи серверов и положил половину интернета.

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

👉 @SQLPortal

Postgres использует TOAST для хранения больших переменных значений вроде JSONB и TEXT.

Использование TOAST влияет на производительность, так что нужно понимать компромиссы.

Каждая строка хранится в файле, который разбит на страницы по 8 KB. Обычно одна страница может держать десятки или сотни строк, но это зависит от количества и типов колонок.

Широкие таблицы могут иметь строки размером в несколько килобайт. Если строка превышает порог (например, около 2 KB), Postgres решает использовать The Oversized-Attribute Storage Technique (TOAST), а не запихивать все данные в основной файл таблицы.

TOAST применяет сжатие и перенос больших значений в отдельную таблицу — TOAST-таблицу. У нее всего три колонки: chunk_id, chunk_seq и chunk_data. Большие значения режутся на чанки, эти чанки кладутся в отдельную таблицу, а в основной таблице остается только ссылка на них.

Это позволяет держать строки в основном файле компактными. Минус в том, что при обращении к таким данным нужно делать дополнительные I/O на другую таблицу (и возможно тратить CPU на декомпрессию). Гибкость в работе с большими полями удобна, но может ударить по перформансу по сравнению с хранением всего в основной таблице или нормализацией данных в компактные фиксированные колонки.

👉 @SQLPortal

❤️ В статье на Хабре Андрей Колнооченко, бэкенд‑разработчик в Яндекс 360, делится опытом масштабной миграции данных из MongoDB в PostgreSQL в Яндекс Диске:

• Как переносили сотни миллионов записей без даунтайма и потерь;
• Почему отказались от распределённых транзакций и как обеспечили согласованность данных;
• Как выкатывали изменения поэтапно — с возможностью отката в любой момент.

Всё это — под высокой нагрузкой, без влияния на пользователей и с полной гарантией доступности сервиса.

↘️ Читайте на Хабре!