Ищем внутри массивов JSON в Oracle SQL с помощью:

JSON_EXISTS(
  json_data, '$.path.to.array?(@ == $var)'
  PASSING 'val' AS $var
)

?(@ == $var) — ищет элементы массива, совпадающие со значением переменной $var

PASSING 'val' AS $var — устанавливает значение переменной $var равным 'val'

👉 @SQLPortal

Вышел pgAdmin 4 v9.3 — свежий релиз удобнейшего инструмента для работы с PostgreSQL

Вот что завезли в этой версии:

> Поддержка пространственных типов PostGIS — теперь ещё удобнее работать с геоданными
> SQL в поле ограничения БД — можно задавать ограничения через SQL
> Улучшено управление ролями и правами
> Поддержка лигатур в шрифтах — код стал ещё читаемее

А ещё исправили кучу багов

🔗 Подробнее: https://www.postgresql.org/about/news/pgadmin-4-v93-released-3068/

👉 @SQLPortal

А вы когда-нибудь задумывались использовать Postgres для выполнения домашки по математике?

В виде SQL-запросов всё выглядит куда проще 😁

👉 @SQLPortal

Преобразуй строки в столбцы в Oracle SQL с помощью:

PIVOT ( agg_fn FOR col IN ( 'val1', 'val2', ... ) )

А столбцы обратно в строки — с помощью:

UNPIVOT ( val FOR col IN ( col1, col2, ... ) )

Киллиан Линч разбирает детали 🤍

👉 @SQLPortal

3 шага для оптимизации многоколончатых индексов

Порядок колонок в индексе имеет решающее значение:

1. Найдите колонки, сравниваемые через = в ваших WHERE-условиях
2. Расположите их по убыванию количества уникальных значений (от большего к меньшему)
3. Колонки, используемые с <, >, или BETWEEN, поместите в конец

👉 @SQLPortal

Вышла PostgreSQL 18 Beta 1 — можно начинать тестить ✍️

— Асинхронный I/O через io_uring → до 3x быстрее на Linux
— Виртуальные вычисляемые колонки (как в Oracle/MySQL)
— Skip scan в B-деревьях
— Параллельное построение GIN-индексов
— Улучшения в OR, IN, MERGE, репликации, логах и конфиге

Финальный релиз ожидается осенью, сейчас — лучшее время гонять бенчмарки и готовить миграции.

> Подробнее:
https://www.postgresql.org/about/news/postgresql-18-beta-1-released-3070/

👉 @SQLPortal

MongoDB в основном написан на C++, но использует JavaScript для своей оболочки и Python — для некоторых инструментов и драйверов.

📌Разберёмся — MongoDB

✰ В основе MongoDB — это NoSQL, документно-ориентированная база данных.

✰ Традиционные реляционные базы хранят данные в таблицах и строках.

Но,

✰ MongoDB внутренне хранит данные в бинарном формате BSON (Binary JSON).

✰ BSON — это надмножество JSON.

✰ Он может представлять всё, что умеет JSON, и дополнительно — типы вроде дат и бинарных данных.

✰ BSON более компактный, чем JSON, что уменьшает объём хранения и повышает производительность.

✰ Такая структура позволяет естественнее представлять реальные объекты и их связи

👉 @SQLPortal

Совет по Postgres: используйте filter вместо case when для условных агрегатных функций

Такой код читается лучше, соответствует идиомам SQL и часто работает быстрее 🤍

👉 @SQLPortal

Вышли обновления PostgreSQL: 17.5, 16.9, 15.13, 14.18 и 13.21

Исправлена уязвимость (CVE-2025-4207) — баг в проверке кодировки GB18030 мог крашить процесс.

Плюс 60+ фиксов:
— Фикс MERGE с DO NOTHING
— Правки BRIN bloom-индексов
— Улучшения в планировщике и логической репликации
— Обновлены часовые пояса (tzdata 2025b)

📌Поддержка 13-й версии заканчивается 13 ноября — пора планировать апгрейд.

Детали и список изменений:
https://www.postgresql.org/about/news/postgresql-175-169-1513-1418-and-1321-released-3072/

👉 @SQLPortal

Новичок в базах данных и ищешь увлекательный способ изучения?

Лови -> «Манга-гид по базам данных» 😁

Узнай о нормализации и SQL, следуя за принцессой Руруной, которая использует базы данных для управления фруктовой империей Королевства Код!

👉 @SQLPortal

Одноразовая загрузка данных с использованием встроенных внешних таблиц в Oracle Database

Этот запрос использует функцию EXTERNAL, содержащую определение внешней таблицы:

SELECT ... FROM EXTERNAL (
  COLUMNS ( ... )
  DEFAULT DIRECTORY ...
  LOCATION ( '<имя_файла>' )
);

То есть, вы можете выполнить одноразовую загрузку данных из файла, находящегося на сервере базы данных, без создания постоянной внешней таблицы — прямо в SQL-запросе 😍

👉 @SQLPortal

Глубокие SQL-вопросы, которые ты боялся задать

1. WHERE против HAVING

WHERE фильтрует строки до группировки,
а HAVING — после неё.

HAVING используют с агрегатами, например, SUM(), чтобы фильтровать уже сгруппированные данные.

2. Что такое "оконные функции" и чем они отличаются от групповых?

Оконные функции (ROW_NUMBER(), SUM() OVER() и др.) работают с набором строк, связанных с текущей, не объединяя их, как GROUP BY

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

3. Что такое CTE и чем они отличаются от подзапросов?

CTE (Common Table Expressions) — это временные именованные результаты, создаваемые с помощью WITH, которые можно использовать в основном запросе.

В отличие от подзапросов, CTE:
• читаются легче,
• могут быть рекурсивными,
• можно использовать несколько раз в одном запросе.

4. Что такое "взаимная блокировка" (Deadlock) и как её избежать?

Deadlock — это когда две транзакции блокируют друг друга, не давая завершиться

Избежать можно так:
• Держите транзакции короткими.
• Всегда обращайтесь к таблицам в одном порядке.
• Добавьте повторные попытки при сбоях.

5. Что такое "секционированные таблицы" и как они ускоряют запросы?

Секционирование делит большую таблицу на части (например, по дате или региону).

Если запрос фильтрует по секционированному столбцу, он пропустит нерелевантные части — это ускоряет выполнение.

6. Что такое "материализованные представления" и чем они отличаются от обычных?

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

Обычные представления данные не хранят, это просто сохранённые запросы

7. Что такое "покрывающий индекс" и зачем он нужен?

Покрывающий индекс содержит все столбцы, нужные для запроса

База может ответить на такой запрос только по индексу, не заглядывая в таблицу — это сильно ускоряет чтение.

👉 @SQLPortal

Совет по psql: настройте файл psqlrc

Если вы часто работаете с psql, создайте файл-шаблон psqlrc с любимыми настройками форматирования и командами. В него можно даже сохранить часто используемые SQL-запросы как пользовательские команды.

Например, чтобы создать команду для просмотра медленных запросов:

\set long_running 'SELECT pid, now() - pg_stat_activity.xact_start AS duration, query, state FROM pg_stat_activity WHERE (now() - pg_stat_activity.x...'

Теперь, когда этот запрос сохранён в psqlrc, достаточно ввести :long_running, чтобы выполнить его и сразу получить результат 😮

👉 @SQLPortal

Раньше я слишком много думал, какую базу данных выбрать.

Тонул в бенчмарках, блогах и маркетинговых обещаниях. 💩 Пока не нашёл эту простую блок-схему.

Она отсекает лишнее и помогает выбрать всего по двум вопросам:

> Какие у тебя данные?
> Что ты с ними делаешь?

Суть такая:

-> Структурированные + OLTP → реляционная БД
-> Структурированные + OLAP → колоночная БД
-> Неструктурированные → объектное хранилище

Полуструктурированные?

> В формате словаря? → Key-Value или In-memory
> Много связей? → графовая БД
> По времени? → time-series БД
> Геоданные? → геопространственная БД
> Вложенный JSON? → документная БД
> Много поиска? → поисковая БД

Эта схема сэкономила мне кучу времени. Возможно, поможет и тебе 💖

👉 @SQLPortal

Совет по SQL:

Всегда следи за индексами и поддерживай их в порядке.
Неиспользуемые или дублирующие индексы = медленные записи и зря занятое место.

Почему это важно?
– Чистые индексы = быстрее вставки и обновления
– Меньше I/O → выше производительность

Используй этот запрос, чтобы найти неиспользуемые индексы в SQL Server 🔍

👉 @SQLPortal

PostgreSQL в Kubernetes

На экране — живая база Postgres, счётчик строк в левом верхнем углу

Сначала мы останавливаем основной pod и удаляем primary — происходит автоматический failover, и выбирается новый лидер через Patroni. Затем мы удаляем каталог PGDATA у текущего Primary — и снова failover.

Хаоса явно недостаточно? 😈

На правой панели видно, как маршрутизация и сетевой трафик автоматически подстраиваются под сбои

👉 @SQLPortal

Чтобы найти самую длинную серию подряд идущих событий (например, дней входа в систему):

1. Убери дубликаты, сгруппировав по дате

2. Назначить одинаковую «группу» для последовательных дней:

dt - ROW_NUMBER() OVER (ORDER BY dt) как grp

3. Сгруппировать по этим grp

4. Отсортируй группы по длине в порядке убывания и возьми самую длинную

👉 @SQLPortal

Если ты используешь секционирование таблицы — есть ли у тебя секция по умолчанию?

Её можно задать так:

CREATE TABLE partman_test.time_taptest_table_default
PARTITION OF partman_test.time_taptest_table DEFAULT;

Иметь дефолтную секцию — хорошая идея на случай, если данные не попадают ни в одну из секций.

Можно настроить уведомления, если туда что-то попадает, или проверять через pg_partman check_default

> Больше деталей — в посте в блоге про default-секцию ❤️

👉 @SQLPortal

Для нагруженных приложений в Postgres есть трюк для повышения производительности — prepared statements (подготовленные выражения).

Prepared statements — это переиспользуемые SQL-запросы, которые пропускают этап планирования, выполняя тот же запрос с разными данными.

Полный запрос в Postgres проходит такие шаги:

1. Парсинг — преобразование SQL в внутренний синтаксис
2. Переписывание/трансформация — применение правил и создание внутренних представлений
3. Планирование — планировщик использует статистику по таблицам и другие данные, чтобы выбрать оптимальный план выполнения
4. Выполнение — собственно выполнение запроса

Prepared statements сохраняют первые 3 шага — при следующем запуске остается только извлечь данные. Postgres может полностью пропустить планирование.

Пример:

Подготовка запроса и создание плана:

PREPARE get_user_by_email (text) AS
SELECT * FROM users WHERE email = $1;

Выполнение с одним параметром:

EXECUTE get_user_by_email('alice@test.com');

С другим параметром:

EXECUTE get_user_by_email('bob@test.com');

Удаление подготовленного выражения:

DEALLOCATE get_user_by_email;

ORM'ы умеют работать с prepared statements, и это важно для разрабов, которым нужна производительность. Со стороны приложения это называется параметризованный запрос — в запросе есть плейсхолдер, а значения подставляются позже. Такой параметризованный запрос превращается в prepared statement на уровне базы.

В Rails это выглядит так:

User.where("email = ?", "alice@example.com")

В Python:

cur.execute("SELECT * FROM users WHERE email = %s", ("alice@example.com",))

👉 @SQLPortal

IBM добавила поддержку PostgreSQL в COBOL для Linux

Да-да, не показалось — теперь в COBOL можно напрямую писать SQL-запросы к PostgreSQL.

— Встроенные SELECT, INSERT, UPDATE, DELETE прямо в COBOL
— Новый препроцессор на основе ECPG
— Работает на Linux x86

Старичок COBOL получил современную БД — корпораты в восторге. 😱

https://www.postgresql.org/about/news/new-postgresql-support-in-ibm-cobol-for-linux-on-x86-3074/

👉 @SQLPortal