SQL Portal | Базы Данных

Каждая база данных Postgres имеет свой профиль нагрузки: одни в основном читают данные, другие — постоянно их записывают. Понимание этого помогает принимать решения по индексам, настройке shared_buffers, WAL, репликам чтения и агрессивности autovacuum.Чтение и запись — не одно и то жеЧтение получает страницу размером 8 КБ из shared_buffers или кэша ОС.Если страница уже закэширована, стоимость операции почти нулевая.Если её приходится читать с диска — это одно физическое чтение.С записью всё сложнее:• Изменение сначала записывается в WAL, и только после этого транзакция может быть подтверждена• При первой записи после checkpoint'а может потребоваться запись всей страницы в WAL (full page write)• Обновляются все связанные индексы• Может выполняться запись в TOAST-таблицы и TOAST-индексы• Страница данных должна находиться в памяти, поэтому запись часто включает дополнительное чтениеИз-за этого одна операция записи по стоимости ввода-вывода обычно заметно дороже одной операции чтения.Настройки для read-heavy нагрузок• shared_buffers и effective_cache_size — чем больше горячих данных помещается в памяти, тем меньше обращений к диску• Индексы на колонках из WHERE, JOIN и ORDER BY — выигрыш от ускорения чтения обычно перекрывает накладные расходы на обновление индексов• Read replicas — позволяют распределить нагрузку от SELECT-запросов без воздействия на primary-узел• EXPLAIN ANALYZE — помогает находить медленные запросы и заменять последовательное сканирование (Seq Scan) на индексное (Index Scan) там, где это оправданоНастройки для write-heavy нагрузок• Быстрые накопители (NVMe SSD, высокий IOPS) — записи нельзя обслуживать только за счёт кэша• Меньше индексов — каждый индекс приходится обновлять при записи; неиспользуемые индексы лучше удалять• HOT Updates и fillfactor — Postgres может обновлять строку без изменения индексов, если индексируемые поля не меняются и на странице есть свободное место• Настройка WAL — wal_buffers уменьшает частоту сбросов WAL, а checkpoint_tim

DBeaver уже 15 лет остаётся де-факто стандартом среди SQL-клиентов.Инструмент мощный, но это ещё и тяжёлый Java-монолит, который может запускаться по 20 секунд.Кто-то решил переписать его с нуля на Rust и добавить возможности, которых в DBeaver никогда не было.Проект называется Tabularis. 2.5 тыс. звёзд. Лицензия Apache 2.0. Последняя активность — 17 часов назад.Самое интересное:Tabularis создал один разработчик — Debba — как эксперимент по AI-assisted разработке.Цель была простой: проверить, насколько далеко AI-агенты способны зайти при создании реального продукта.В итоге получилось 55 релизов, 1192 коммита и SQL-клиент, который уже конкурирует с продуктами компаний, где над подобными инструментами работают десятки инженеров.Что есть в Tabularis, а в DBeaver нет:✅ Встроенный MCP-сервер — Claude, Cursor и Windsurf могут читать схему БД и выполнять запросы прямо из чата✅ SQL Notebooks с графиками внутри ячеек и общими переменными между ними✅ Визуальный EXPLAIN с AI-анализом плана выполнения✅ Визуальный конструктор запросов с drag-and-drop JOIN'ами✅ Автоматическая генерация ER-диаграмм✅ Поддержка PostgreSQL, MySQL/MariaDB, SQLite и ClickHouse через плагины✅ Редактор на базе Monaco с интеллектуальным автодополнением✅ Без телеметрии, аккаунтов и подписокЧего пока нет в Tabularis, но есть в DBeaver:❌ SQL Server❌ OracleЕсли работаешь с ними, DBeaver пока остаётся более очевидным выбором.Во всех остальных случаях Tabularis запускается примерно за 2 секунды, занимает меньше ресурсов и позволяет AI-агентам работать с базой напрямую.https://github.com/TabularisDB/tabularis👉 @SQLPortal

В SQL можно объединять таблицы по одинаковым именам колонок через:t1 JOIN t2 USING (c1)Но здесь есть неприятная ловушка Такой запрос:t1JOIN t2 USING (c1)JOIN t3 USING (c2)будет работать, если c2 есть только в t2 и t3.Проблемы начинаются позже.Если в будущем кто-то добавит колонку c2 в t1, запрос внезапно перестанет работать или начнёт вести себя не так, как ожидалось.Причина в том, что USING опирается на имена колонок, а не на явные ссылки на таблицы. Изменение схемы может неожиданно повлиять на уже существующие JOIN'ы.Именно поэтому многие разработчики предпочитают более явный вариант:t1JOIN t2 ON t1.c1 = t2.c1JOIN t3 ON t2.c2 = t3.c2Кода чуть больше, зато зависимость от структуры таблиц становится очевидной и предсказуемой.Лукас Эдер показывает этот кейс на простом примере и напоминает, что некоторые удобные сокращения в SQL могут обернуться проблемами спустя месяцы или годы.https://blog.jooq.org/why-join-using-can-lead-to-errors-in-sql/👉 @SQLPortal

Написать медленный запрос в Postgres сегодня гораздо сложнее, чем раньше. Запрос может содержать полное сканирование таблицы, крупную сортировку или дорогую агрегацию, но всё равно выполняться быстро. Современный Postgres просто подключает параллельных воркеров.Параллелизм скрывает стоимость тяжёлых запросов, но не устраняет её. Индексы и механизмы кэширования уменьшают объём работы, который нужно выполнить.Параллельное выполнение всё равно делает тот же объём работы — оно лишь распределяет его между несколькими процессорами. Воркеры позволяют задействовать больше CPU, но не сокращают количество операций. Если запрос выполняет полное сканирование таблицы, он всё равно прочитает всю таблицу. Просто сделает это быстрее за счёт дополнительных CPU.На первый взгляд безобидный запрос:SELECT user_id, count(*) AS total_eventsFROM eventsGROUP BY user_idORDER BY total_events DESCLIMIT 10;Предположим, что индексов нет, таблица events содержит 1 000 000 строк и 10 000 уникальных user_id. Такой запрос выполняет большой объём работы. В любом случае ему придётся прочитать каждую строку таблицы.Параллельный конвейер PostgresPostgres разделил таблицу на три части, выполнил агрегацию параллельно и затем объединил результаты.[см. изображение с выводом EXPLAIN ANALYZE]loops=3 для Seq ScanWorkers Launched: 2 (лидирующий процесс + 2 воркера = всего 3 процесса)Partial HashAggregate выполняется в каждом воркеререзультаты объединяются через Finalize HashAggregate в лидирующем процессеНесмотря на высокую скорость выполнения, это не лучший вариант для OLTP-базы данных.При высокой конкурентной нагрузке пул воркеров становится узким местом. Запрос может работать быстро, пока ресурсов хватает, но заметно замедляться при конкуренции за CPU. Запросы с нестабильным временем выполнения — хорошие кандидаты для оптимизации.Параллельные воркеры не заменяют здоровую архитектуру базы данных:Добавляйте индексы, чтобы избежать полного сканирования таблиц и дорогостоящих сортировок.Используйте summary-таб

В Oracle AI Database 26ai теперь можно определять функции и модули на JavaScript прямо в базе данных.CREATE FUNCTION ... MLE LANGUAGE JAVASCRIPT ...CREATE MLE MODULE ... LANGUAGE JAVASCRIPT ...Это позволяет публиковать JavaScript-код, который затем можно вызывать напрямую из SQL.#JavaScript #OracleDatabase #SQL #MLE👉 @SQLPortal

Сегодня на практике разбирался с обработкой ошибок в SQL.Что сделал:→ Написал хранимую процедуру для добавления заказов в базу данных Sales→ Обернул её в блок TRY/CATCH→ При ошибке сохраняются точные значения ERROR_MESSAGE() и ERROR_NUMBER()→ Никаких тихих падений и гаданий. База данных сама сообщает, что пошло не так.Почему это важно:→ Пайплайны ломаются→ Данные бывают грязными→ Ошибки неизбежныПайплайн без обработки ошибок — это пайплайн, которому нельзя доверять.В этом и разница между SQL-кодом, который работает на твоём ноутбуке, и SQL-кодом, который выдерживает продакшен.#DataEngineering #BuildInPublic #SQL👉 @SQLPortal

Большинство SQL-разработчиков умеют писать запросы.Но лишь немногие понимают, что происходит автоматически после изменения данных.Если хочешь разобраться в SQL-триггерах, изучи следующие темы:1. BEFORE Triggers — триггеры, выполняющиеся до изменения данных.2. AFTER Triggers — триггеры, выполняющиеся после изменения данных.3. INSTEAD OF Triggers — триггеры, которые заменяют выполнение операции.4. Row-Level Triggers — триггеры, срабатывающие для каждой строки.5. Statement-Level Triggers — триггеры, срабатывающие один раз на SQL-оператор.6. Audit Logging — аудит и журналирование изменений.7. Data Validation — проверка данных.8. Soft Deletes — логическое удаление записей.9. Business Rule Enforcement — обеспечение соблюдения бизнес-правил.10. Trigger Performance — производительность триггеров.11. Nested Triggers — вложенные триггеры.12. Best Practices для Production — практики использования триггеров в боевых системах.Освоив эти темы, ты поймёшь, как корпоративные базы данных автоматизируют бизнес-логику в крупных системах.👉 @SQLPortal

Два data engineer-а спроектировали один и тот же warehouse.Design A - SQL- ETL- Star Schema- Data WarehouseDesign B - Spark- Data Lakehouse- Medallion Architecture- Real-Time AnalyticsКакой дизайн согласуют?A. Design AB. Design BПодвох: в компании всего 50 сотрудников.Защити свой ответ.👉 @SQLPortal

Некоторые люди — как Kafka.Постоянно что-то стримят, никогда не останавливаются. Некоторые — как DuckDB.Их недооценивают, пока они не начинают работать на безумной скорости. Некоторые — как Airflow.Тихо координируют всё происходящее за кулисами. Некоторые — как Apache Iceberg.Долго раскачиваются, зато рассчитаны на долгую дистанцию. Дата твоего рождения покажет, кто ты на самом деле.Ищи себя ниже 👇

Сегодня ковырялся в Stored Procedures в SQL.По сути, Stored Procedure — это сохранённый набор SQL-инструкций внутри базы данных. Написал один раз, потом вызываешь сколько угодно раз.Сегодня разобрал три вещи:• IF / ELSE• Обработку ошибок• Нормальный стиль написания процедур1. IF / ELSEStored Procedures умеют принимать решения.Логика такая же, как в обычном коде:IF условие выполнить действиеELSE выполнить другое действиеНапример, проверить, сдал студент экзамен или нет:IF @Score >= 50 PRINT 'You passed!';ELSE PRINT 'You failed.';Точно так же можно проверять:право голоса по возрасту;наличие товара на складе;скидки для клиентов;права администратора;любые бизнес-правила.Теперь стало понятно, что IF ELSE — это основной способ управлять логикой внутри процедуры.2. Обработка ошибокРано или поздно что-то ломается:деление на ноль;дубликаты данных;обновление несуществующих записей;ошибки во время денежных переводов.Для таких случаев в SQL Server есть:BEGIN TRY -- основной кодEND TRYBEGIN CATCH -- обработка ошибкиEND CATCHПример:BEGIN TRY SELECT @Number1 / @Number2;END TRYBEGIN CATCH PRINT 'Division by zero.';END CATCHПолезная штука:ERROR_MESSAGE()Позволяет получить текст реальной ошибки:PRINT ERROR_MESSAGE();Ещё посмотрел на транзакции.Идея простая:либо выполняются все операции, либо не выполняется ни одна.Для денежных переводов это критично.Если одна из операций упала:ROLLBACK TRANSACTION;База откатит изменения и не останется в промежуточном состоянии.3. Стиль написания Stored ProceduresSQL быстро превращается в кашу, если писать как попало.Плохой вариант:create procedure getstudents as begin select * from students endНормальный вариант:CREATE PROCEDURE GetStudentsASBEGIN SELECT * FROM Students;END;Что стоит соблюдать:понятные названия процедур;понятные названия параметров;SQL-ключевые слова в верхнем регистре;отступы;комментарии только там, где они реально нужны;аккуратная структура кода.Ещё узнал про:SET NOCOUNT ON;Эта команда отключает лишние

Oracle AI Database 23.26.1 получила поддержку partition by expression.Теперь секционировать таблицы можно прямо по выражению, а не только по отдельному столбцу.Например, можно автоматически раскладывать записи по доменам верхнего уровня из email:PARTITION BY LIST ( REGEXP_SUBSTR(email_address, '[^.]+$'))То есть .com, .org, .net и другие TLD будут попадать в свои партиции без создания отдельного вычисляемого столбца.Небольшая фича, которая убирает лишний слой костылей в схемах БД.Демонстрация от Dani Schnider -https://danischnider.wordpress.com/2026/05/22/partition-by-expression/👉 @SQLPortal

Нумеровать строки в SQL можно по-разномуROW_NUMBER() — уникальный порядковый номер для каждой строкиDENSE_RANK() — одинаковый ранг для одинаковых значений, без пропусков в нумерацииRANK() — одинаковый ранг для одинаковых значений, после совпадений появляются пропускиПример:score-----1001009080ROW_NUMBER()1234DENSE_RANK()1123RANK()1134Джесс Рамос показывает разницу между этими функциями на практике и разбирает типичные сценарии их использования.👉 @SQLPortal

В PostgreSQL 19 Beta 1 завезли ON CONFLICT DO SELECT.Теперь можно попытаться вставить запись, а если она уже есть — сразу получить существующую.Похоже, атомарный get-or-create наконец добрался до PostgreSQL. #PostgreSQL #SQL👉 @SQLPortal

10 SQL-проверок качества данных, которые стоит внедрить в любом проекте👉 @SQLPortal

Вышел Extend UI — open-source набор компонентов для документных агентов.Что внутри:✓ 14 готовых компонентов и примеров✓ Просмотр PDF, DOCX и XLSX✓ Bounding box citations✓ Загрузка файлов✓ Электронная подпись✓ Полная кастомизация✓ MIT-лицензияКоманда перепробовала десятки просмотрщиков документов и UI-библиотек, но ни одна не закрывала все их требования по функциональности и UX.В итоге они собрали собственное решение для Extend.Изначально проект был внутренним инструментом, но после многочисленных запросов клиентов его решили открыть для сообщества.Подойдёт для агентных систем, пользовательских документных сценариев и внутренних корпоративных инструментов.Бонус: компонентами уже ежедневно пользуются на миллионах страниц документов внутри Extend, так что проект успел пройти хорошую проверку в продакшене.👉 @SQLPortal