Выбор девушки.

👉 @SQLPortal

Внешние таблицы — отличный способ читать текстовые файлы в Oracle Database с помощью SQL.

Но что, если у тебя есть поля длиннее 4000 символов?

Anti Kyte разбирает:

I. Маппинг CHAR в ACCESS PARAMETERS на CLOB
II. Увеличение READSIZE
III. Использование big data driver

👉 @SQLPortal

У Postgres есть огромное преимущество перед MySQL в плане поддержки транзакций.

Большинство операторов CREATE, ALTER и DROP в Postgres являются полноценными участниками многооператорных транзакций. Это означает, что их можно использовать между BEGIN и COMMIT, и все изменения либо успешно применяются, либо откатываются атомарно вместе со всеми другими операторами.

В MySQL это не так. Подобные операторы работают по модели неявного коммита: при выполнении CREATE, ALTER или DROP происходит автоматический коммит текущей транзакции.

Таким образом, в Postgres можно, например:

- создать таблицу и вставить в неё данные в рамках одного атомарного действия,
- атомарно изменить несколько таблиц.

👉 @SQLPortal

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

Есть задачи на работу с запросами, оптимизацию, подзапросы, агрегации и даже отдельный блок, посвящённый вопросам, встречающимся в интервью у компаний уровня FAANG. 🥸

👉 @SQLPortal

Консистентность «read-your-writes» означает, что любая запись, сделанная в базу данных, сразу становится доступной для чтения тем же клиентом.

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

На сервере с одной нодой это легко гарантировать при использовании последовательных транзакций.

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

Такое возможно при использовании асинхронной или полусинхронной репликации, так как они не требуют, чтобы все реплики получили данные до ответа клиенту. При синхронной репликации primary отвечает только после того, как все реплики подтвердят получение записи.

Если используется асинхронная или полусинхронная репликация, чтения на реплики лучше направлять только тогда, когда консистентность «read-your-writes» не критична.

👉 @SQLPortal

Вышел бесплатный онлайн-плейграунд для SQL — RunSQL.

Сервис позволяет создавать таблицы, писать запросы и делиться результатами с командой. Поддерживаются MySQL, PostgreSQL и SQL Server.

Работает прямо из браузера, ничего устанавливать не нужно: https://runsql.com/r

👉 @SQLPortal

Индексы covering дают серьезный прирост производительности, если использовать их правильно

Covering index это индекс, который покрывает все колонки, нужные для результата запроса, без обращения к основной таблице. В Postgres это значит, что можно обойтись без table heap, а в MySQL без обращения к clustered index данных таблицы

Например, запрос:

SELECT name, email
FROM user
WHERE name > 'C' AND name < 'G';

Если есть индекс только по name

CREATE INDEX idx_name
ON your_table (name);

База сможет использовать индекс для фильтрации, но всё равно придется искать email в основной таблице

Если же создать составной индекс

CREATE INDEX idx_name_email
ON your_table (name, email);

То все нужные колонки уже есть в индексе, и запрос отрабатывает быстрее

Минус в том, что индекс становится больше. Классический компромисс между пространством и временем

👉 @SQLPortal

Простое объяснение соединений в базах данных:

Соединения позволяют связывать разные таблицы на основе их отношений.

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

Основные типы соединений:

1. Inner Join – возвращает только те строки, которые совпадают в обеих таблицах.
2. Left (Outer) Join – возвращает все строки из левой таблицы и только совпадающие строки из правой.

Другие виды соединений:

- Self Join – соединение таблицы самой с собой.
- Outer Join – включает все строки из обеих таблиц с учетом совпадений и неполных данных.
- Cross Join – декартово произведение двух таблиц, каждая строка первой таблицы соединяется со всеми строками второй.

👉 @SQLPortal

Фича Postgres 18: дамп статистики таблиц

В Postgres 18 появится возможность использовать pg_dump --statistics-only и --with-statistics

👉 @SQLPortal

Новый уровень баз данных

Turso это впечатляющий технический проект. Это переписанный на Rust SQLite с архитектурой async-first, готовящейся поддержкой конкурентных записей, векторным поиском и встроенной поддержкой браузера / WASM.

Есть все шансы, что он станет фундаментальной частью инфраструктуры «vibe-coding» эпохи: on-demand, глобальные базы данных, совместимые с SQLite, которые можно запускать как в браузере, так и локально на устройстве.

Скорость, с которой развивается проект, это явно что-то необычное. 🐱

Демо: shell.turso.tech

@SQLPortal

PostgreSQL получил полезное обновление для разработчиков

Теперь блокировка FOR NO KEY UPDATE официально помогает избегать проблем с параллельной вставкой в дочерние таблицы.

Ранее использование классического FOR UPDATE на родительской записи могло блокировать добавление связанных строк, например комментариев к посту. С FOR NO KEY UPDATE родительскую запись можно защищать от изменений, не мешая вставке дочерних данных. Это ускоряет работу баз и повышает параллельность операций, особенно в сложных схемах с внешними ключами.

Подробнее о механике и примерах использования можно почитать на блоге Владислава Михалчева

👉 @SQLPortal

Совет для psql: \dn — показывает все схемы.

Часто вы подключаетесь к базе данных в схеме по умолчанию или в public. Команда \dn позволяет увидеть другие схемы.

Схема является частью поискового пути psql (search_path), поэтому чтобы сменить схему, нужно изменить поисковый путь:

SET search_path TO new_schema;

👉 @SQLPortal

Полный курс по SQL от основ до продвинутого уровня

Репозиторий SQL-Tutorials от разработчика GowthamRaj K представляет собой обширный ресурс для изучения SQL, идеально подходящий для начинающих и тех, кто хочет систематизировать свои знания.

👉 @SQLPortal

PostgreSQL испытывает трудности при росте числа подключений

Даже умеренное количество клиентов может «сломать» PostgreSQL. Причина в том, как СУБД обрабатывает каждое соединение.

При подключении нового клиента процесс postmaster создаёт отдельный бэкенд-процесс (не поток) для работы с сессией. Этот процесс поддерживает соединение до отключения клиента или потери соединения.

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

Решение — использовать пул соединений, например, pg_bouncer. Менеджер пула держит заранее созданные соединения с базой и выдаёт их клиентам по мере необходимости, вместо того чтобы создавать новое соединение для каждого запроса. Это позволяет обслуживать больше клиентов при меньшем количестве соединений к базе.

Интересный факт, существует предложение перевести PostgreSQL на многопоточную модель вместо текущей многопроцессной, что потенциально могло бы решить проблему масштабируемости.

Детальный разбор того, как PostgreSQL управляет соединениями

👉 @SQLPortal

Новости: Выпущен PostgreSQL 18!

https://www.postgresql.org/about/news/postgresql-18-released-3142/

👉 @SQLPortal

Создавайте blockchain-таблицы в Oracle Database с помощью

CREATE BLOCKCHAIN TABLE ... ( ... )
NO DROP UNTIL n DAYS IDLE
NO DELETE UNTIL n DAYS AFTER INSERT
HASHING USING SHA2_512 VERSION "v1"

Эти параметры:

- разрешают INSERT,
- запрещают UPDATE,
- запрещают DELETE/DROP до истечения заданного количества дней (N).

👉 @SQLPortal