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

Подарок для новичков: бесплатный интерактивный курс «Aprende SQL»

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

Ставь лайк и погнали учиться ❤️

☝️ Ссылка источник

@SQLPortal

Хочешь быстро прокачать SQL?

Вот 4 курса, которые помогут поднять уровень:

1️⃣ SQL Basics for Data Science
[https://programmingvalley.com/course/learn-sql-basics-for-data-science-free-course]

2️⃣ Google Data Analytics
[https://programmingvalley.com/course/google-data-analytics-free-course]

3️⃣ IBM Data Science
[https://programmingvalley.com/course/ibm-data-science-free-course]

4️⃣ Google Business Intelligence
[https://programmingvalley.com/course/google-business-intelligence-free-course]

Подойдут как для изучения основ SQL, так и для освоения анализа данных, BI-инструментов и работы с данными в реальных проектах.

👉 @SQLPortal

Что нового в PostgreSQL 19?

PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.

Самые интересные новинки:

Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.

GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.

WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».

Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.

PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.

👉 @SQLPortal

SQL JOINs: мини-шпаргалка

Простая и наглядная памятка по основным JOIN-операциям в SQL: схемы, запросы и краткие пояснения

Сохраняем за лайк ❤️

👉 @SQLPortal

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

Любой пайплайн начинается с основ: как перемещаются данные, где они хранятся и как различные системы взаимодействуют друг с другом.

Дальше идёт фундамент:

• SQL для работы с данными и запросов
• Python для автоматизации задач
• Базы данных для хранения информации
• Хранилища данных (Data Warehouses) для аналитики
• Облачные платформы для масштабирования систем

Когда эти основы становятся понятны, можно переходить следующему этапу. Вы учитесь очищать и обрабатывать «грязные» данные, проектировать надёжные модели, работать со Spark, разбираться в форматах файлов, строить сквозные пайплайны и использовать инструменты оркестрации, такие как Airflow, Dagster или Prefect.

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

Потому что Data Engineering — это не только знание инструментов. Это понимание полного жизненного цикла данных:

Источник → Сбор → Хранение → Преобразование → Предоставление

Эта схема объединяет весь путь в одном месте: от фундаментальных знаний до проектов, полезных ресурсов, каналов для обучения и шагов по созданию собственного портфолио.

Важное напоминание для всех новичков:

• Начинайте с малого.
• Развивайтесь последовательно.
• Осваивайте по одному уровню за раз.
• Делитесь тем, что создаёте.

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

👉 @SQLPortal

PostgreSQL 19 — это гораздо больше, чем просто развитие поддержки JSON.

Что появится в новой версии:

→ графовые запросы через SQL/PGQ
→ GROUP BY ALL
→ REPACK CONCURRENTLY
→ параллельный autovacuum
→ логическая репликация без перезапуска сервера
→ репликация sequence
→ более подробный ввод-вывод в EXPLAIN ANALYZE
→ новые представления pg_stat_lock и pg_stat_recovery
→ онлайн-проверка контрольных сумм (checksums)

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

👉 @SQLPortal

Ближайший релиз PostgreSQL 19 получит поддержку графовых запросов.

С помощью SQL/PGQ можно будет работать со связями напрямую через SQL:

→ социальные сети
→ рекомендательные системы
→ выявление мошенничества
→ графы зависимостей

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

Он постепенно превращается в универсальную платформу для хранения и обработки данных любых типов.

👉 @SQLPortal

В Oracle AI Database 26ai появилась возможность управлять тем, попадают ли ограничения базы данных в JSON Schema.
Для этого используются два режима

PRECHECK — включает ограничения БД в JSON Schema.
NOPRECHECK — исключает ограничения из JSON Schema.

Если использовать PRECHECK, ограничения вроде NOT NULL, CHECK, диапазонов значений и других правил будут перенесены в JSON Schema. Это позволяет приложениям выполнять валидацию ещё до отправки данных в базу.
При использовании NOPRECHECK ограничения не включаются в схему, а проверка и определение допустимых значений остаются на стороне базы данных.

Функция доступна в Oracle AI Database 26ai и помогает синхронизировать правила валидации между БД и приложением.

👉 @SQLPortal

На выходных разбирался с WAL (Write-Ahead Log) в PostgreSQL.

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

За WAL стоят буферы, контрольные точки (checkpoints), фоновая запись (background writer), LSN у страниц, процессы восстановления после сбоев и ещё много механизмов, которые работают вместе.

Ниже — сильно упрощённая схема, но она помогла мне лучше понять общую картину и то, как PostgreSQL обеспечивает надёжность данных.

Нашёл бесплатный сайт для изучения SQL в формате интерактивных упражнений.

https://www.aprendesql.dev/

👉 @SQLPortal

Кстати, если пропустили:

Вышла Oracle AI Database 23.26.2 Free.
Можно скачать и попробовать новые возможности SQL, включая:

JOIN TO ONE
WAIT/NOWAIT для DML-операций
вложенные WITH-выражения (Nested WITH)

https://www.oracle.com/database/free/get-started/

👉 @SQLPortal

Общие табличные выражения (Common Table Expressions, CTE), известные по ключевому слову WITH, позволяют создавать именованные подзапросы:

WITH cte AS (
    SELECT ...
)
SELECT *
FROM cte;

CTE помогают упростить сложные SQL-запросы и сделать их более читаемыми.
Вместо вложенных подзапросов на несколько уровней можно разбить логику на отдельные именованные блоки и затем использовать их как обычные таблицы в основном запросе.

Преимущества:
→ улучшают читаемость сложных запросов
→ позволяют повторно использовать промежуточные результаты
→ упрощают отладку и поддержку SQL-кода
→ поддерживают рекурсивные запросы через WITH RECURSIVE

Baraa Khatib Salkini наглядно показывает, как работают CTE и почему они делают сложные SQL-запросы гораздо понятнее.

👉 @SQLPortal

Каждая база данных 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_timeout и checkpoint_completion_target помогают сглаживать пики нагрузки во время checkpoint'ов
• Более крупный shared_buffers — грязные страницы должны находиться в памяти до их записи на диск, поэтому дополнительная память может улучшить производительность систем с интенсивной записью.

👉 @SQLPortal

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)

Но здесь есть неприятная ловушка
Такой запрос:

t1
JOIN t2 USING (c1)
JOIN t3 USING (c2)

будет работать, если c2 есть только в t2 и t3.

Проблемы начинаются позже.

Если в будущем кто-то добавит колонку c2 в t1, запрос внезапно перестанет работать или начнёт вести себя не так, как ожидалось.
Причина в том, что USING опирается на имена колонок, а не на явные ссылки на таблицы. Изменение схемы может неожиданно повлиять на уже существующие JOIN'ы.

Именно поэтому многие разработчики предпочитают более явный вариант:

t1
JOIN t2 ON t1.c1 = t2.c1
JOIN 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_events
FROM events
GROUP BY user_id
ORDER BY total_events DESC
LIMIT 10;

Предположим, что индексов нет, таблица events содержит 1 000 000 строк и 10 000 уникальных user_id. Такой запрос выполняет большой объём работы. В любом случае ему придётся прочитать каждую строку таблицы.
Параллельный конвейер Postgres

Postgres разделил таблицу на три части, выполнил агрегацию параллельно и затем объединил результаты.
[см. изображение с выводом EXPLAIN ANALYZE]

loops=3 для Seq Scan
Workers Launched: 2 (лидирующий процесс + 2 воркера = всего 3 процесса)
Partial HashAggregate выполняется в каждом воркере
результаты объединяются через Finalize HashAggregate в лидирующем процессе

Несмотря на высокую скорость выполнения, это не лучший вариант для OLTP-базы данных.
При высокой конкурентной нагрузке пул воркеров становится узким местом. Запрос может работать быстро, пока ресурсов хватает, но заметно замедляться при конкуренции за CPU. Запросы с нестабильным временем выполнения — хорошие кандидаты для оптимизации.

Параллельные воркеры не заменяют здоровую архитектуру базы данных:
Добавляйте индексы, чтобы избежать полного сканирования таблиц и дорогостоящих сортировок.
Используйте summary-таблицы или materialized view, чтобы не выполнять тяжёлые агрегации на больших объёмах данных.
Разбивайте time-series таблицы на партиции, чтобы уменьшить объём данных, который приходится сканировать в типовых запросах.

👉 @SQLPortal

В 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