Ответ.

История вопроса

Появление крупных хранилищ и потоков данных (ETL, миграции) потребовало не просто загружать сотни тысяч строк, но и гарантировать, что данные либо загрузятся полностью, либо не загрузится ничего. В SQL это реализуется через атомарные bulk-операции с помощью транзакций.

Проблема

При массовой вставке (Bulk Insert) риск ошибки выше — один некорректный ряд может испортить всю загрузку или привести к частичной вставке. Это недопустимо для финансовых, логистических и других критичных систем.

Решение

Практика — оборачивать bulk-операцию в транзакцию, использовать подходящие специальные команды (BULK INSERT, COPY) и ловить/логировать ошибки. Важно: при ошибке любой строки происходит откат всего блока:

Пример для SQL Server:

BEGIN TRAN;
BULK INSERT Customers
FROM 'C:\data\customers.csv'
WITH (
    FIELDTERMINATOR = ',',
    ROWTERMINATOR = '
',
    FIRSTROW = 2
);
IF @@ERROR <> 0 ROLLBACK TRAN; ELSE COMMIT TRAN;

В PostgreSQL (пример с COPY):

BEGIN;
COPY products FROM '/tmp/products.csv' DELIMITER ',' CSV HEADER;
COMMIT;

Ключевые особенности:

Гарантия «всё или ничего» (atomicity)
Высокая скорость загрузки за счет пакетной обработки
Возможность обрабатывать ошибки с записью проблемных строк

Вопросы с подвохом.

Влияет ли размер транзакции при Bulk Insert на производительность и блокировки?

Да, при слишком больших объемах можно получить длительную блокировку, переполнить логи транзакций и замедлить сервер. Лучшее — загружать порциями (batch), например по 10000 строк за транзакцию.

Является ли Bulk Insert всегда транзакционным по умолчанию во всех СУБД?

Нет, в некоторых СУБД (например, MySQL) команда bulk insert не всегда автоматически атомарна — требуется обернуть её в BEGIN/COMMIT вручную, иначе возможна частичная загрузка.

Можно ли гарантировать целостность внешних ключей при массовой вставке?

Да, только если порядок загрузки соблюдается: сначала родительские таблицы, потом дочерние, либо временно отключать констрейнты. Ошибка внешнего ключа откатит всю транзакцию bulk insert.

Типовые ошибки и анти-паттерны

Попытка загрузить слишком большой файл за одну операцию, приводящая к переполнению памяти и log файлов
Пренебрежение логированием ошибок — сложно выяснять, почему данные некорректны
Нарушение порядка загрузки связанных таблиц с внешними ключами

Пример из жизни

Негативный кейс

В процессе загрузки клиентов файл с ошибкой в одной строке привёл к частичной загрузке — к концу дня база и внешний источник рассинхронизировались

Плюсы:

Экономия на структуре кода, простая реализация Минусы:
Потеря данных, приводящая к сбоям в бизнес-логике

Позитивный кейс

Файл предварительно проверяется на ошибки, Bulk insert разбит на порции по 5000 строк, каждая порция в своей транзакции. Логи ошибок сохраняются для дальнейшего анализа.