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

MERGE: атомарная вставка или обновление!

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

Создаём таблицу:

CREATE TABLE clients (
    id NUMBER PRIMARY KEY,
    name VARCHAR2(200) NOT NULL,
    email VARCHAR2(200) UNIQUE NOT NULL,
    updated_at DATE DEFAULT SYSDATE NOT NULL
);

Подготавливаем входящие данные с помощью CTE:

WITH incoming AS (
    SELECT 10 AS id,
           'Ivan Petrov' AS name,
           'ivan@example.com' AS email
    FROM dual
)

Здесь мы формируем набор входных данных, который будет использован оператором MERGE как источник.

Теперь выполняем MERGE, используя CTE как таблицу-источник:

MERGE INTO clients c
USING incoming i
ON (c.id = i.id)
WHEN MATCHED THEN
    UPDATE SET
        c.name = i.name,
        c.email = i.email,
        c.updated_at = SYSDATE
WHEN NOT MATCHED THEN
    INSERT (id, name, email, updated_at)
    VALUES (i.id, i.name, i.email, SYSDATE);

Операция выполняется одной DML-командой, что исключает необходимость выполнять отдельный SELECT.

Проверяем результат:

SELECT * FROM clients WHERE id = 10;

🔥 Пример выше предназначен для Oracle. Оператор MERGE также поддерживается в SQL Server, DB2, Snowflake, BigQuery и PostgreSQL 15+. Синтаксис в разных СУБД может отличаться.

➡️ SQL Ready | #практика

🖥 Как база выбирает путь выполнения?

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

Сегодня в гайде:

• Почему SQL переставляет JOIN’ы и фильтры;

• Как нестабильные функции и устаревшая статистика меняют план;

• Где оптимизатор может дать неожиданный результат по производительности.

Понимание оптимизатора показывает, какие шаги реально выполняет база и почему выбран именно такой план.

➡️ SQL Ready | #гайд

🖥 SQLite: оптимизация работы с большими объёмами данных!

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

➡️ SQL Ready | #шпора

Знали, как найти отличия между двумя версиями таблицы?

SQL умеет находить уникальные строки сам:

SELECT * FROM snapshot_new
EXCEPT
SELECT * FROM snapshot_old;

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

Нужно увидеть удалённые строки? Поменяйте местами таблицы:

SELECT * FROM snapshot_old
EXCEPT
SELECT * FROM snapshot_new;

Хотите собрать все расхождения одной командой - и добавленные, и удалённые:

(
  SELECT *, 'added' AS diff
  FROM snapshot_new
  EXCEPT
  SELECT *, 'added'
  FROM snapshot_old
)
UNION ALL
(
  SELECT *, 'removed' AS diff
  FROM snapshot_old
  EXCEPT
  SELECT *, 'removed'
  FROM snapshot_new
);

🔥 Теперь видно список всех отличий с указанием, что именно произошло: добавилось или исчезло.

➡️ SQL Ready | #совет

🖥 Симуляция очереди: кто получит ресурс первым!

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

В этом посте:

• Разберём, как упорядочить поток задач так, чтобы высокий приоритет перехватывал очередь;

• Построим механизм, который при равных приоритетах будет соблюдать FIFO и не нарушать логику поступления задач;

• Получим итоговый порядок обработки.

Техника помогает понять, как моделировать поведение планировщиков, прогнозировать задержки и анализировать нагрузку.

➡️ SQL Ready | #задача

SAVEPOINT: частичный откат без пересборки всей транзакции!

При работе с многошаговыми транзакциями важно уметь откатывать только часть выполненных действий. SAVEPOINT даёт такой контроль в большинстве СУБД. Пример ниже оформлен для Oracle, но принцип похож и в других диалектах.

Создаём таблицу:

CREATE TABLE operations (
    id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    description VARCHAR2(200),
    amount NUMBER(10,2) CHECK (amount > 0)
);

Добавляем первую операцию:

INSERT INTO operations (description, amount)
VALUES ('Initial payment', 150.00);

Фиксируем точку сохранения:

SAVEPOINT sp_step1;

Выполняем шаг, который формально корректен, но позже мы решаем его отменить (например, неверная сумма):

INSERT INTO operations (description, amount)
VALUES ('Wrong amount', 1000.00);

Понимаем, что значение было ошибочным, и откатываемся к точке сохранения, не трогая всю транзакцию целиком:

ROLLBACK TO sp_step1;

Выполняем корректную альтернативу:

INSERT INTO operations (description, amount)
VALUES ('Corrected entry', 75.00);

Фиксируем изменения и проверяем результат:

COMMIT;

SELECT * FROM operations;

🔥 Такой подход позволяет в одной транзакции безопасно откатывать только ошибочные шаги, сохраняя корректные операции.

➡️ SQL Ready | #практика