Respuesta.

Historia de la pregunta

La aparición de grandes almacenes y flujos de datos (ETL, migraciones) requirió no solo cargar cientos de miles de filas, sino también garantizar que los datos se carguen por completo o no se cargue nada. En SQL, esto se implementa a través de operaciones masivas atómicas mediante transacciones.

Problema

Durante la inserción masiva (Bulk Insert), el riesgo de error es mayor: una fila incorrecta puede arruinar toda la carga o llevar a una inserción parcial. Esto es inaceptable para sistemas críticos como financieros y logísticos.

Solución

La práctica es envolver la operación masiva en una transacción, utilizar comandos especiales adecuados (BULK INSERT, COPY) y capturar/loguear errores. Importante: si hay un error en cualquier fila, se revierte todo el bloque:

Ejemplo para 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;

En PostgreSQL (ejemplo con COPY):

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

Características clave:

Garantía de "todo o nada" (atomicidad)
Alta velocidad de carga gracias al procesamiento por lotes
Posibilidad de manejar errores registrando filas problemáticas

Preguntas con trampa.

¿Influye el tamaño de la transacción en el rendimiento y los bloqueos durante el Bulk Insert?

Sí, con volúmenes demasiado grandes se puede obtener un bloqueo prolongado, desbordar los registros de transacciones y ralentizar el servidor. Lo mejor es cargar en porciones (batch), por ejemplo, 10000 filas por transacción.

¿Es Bulk Insert siempre transaccional por defecto en todas las bases de datos?

No, en algunas bases de datos (por ejemplo, MySQL) el comando de inserción masiva no siempre es atómico automáticamente; se requiere encapsularlo en BEGIN/COMMIT manualmente, de lo contrario, puede haber carga parcial.

¿Se puede garantizar la integridad de las claves externas durante la inserción masiva?

Sí, solo si se respeta el orden de carga: primero las tablas padre, luego las tablas hija, o desactivando temporalmente las restricciones. Un error de clave externa revertirá toda la transacción de inserción masiva.

Errores comunes y anti-patrones

Intentar cargar un archivo demasiado grande en una sola operación, lo que lleva a desbordamiento de memoria y archivos de registro
Desdén por el registro de errores: es difícil averiguar por qué los datos son incorrectos
Violación del orden de carga de tablas relacionadas con claves externas

Ejemplo de la vida real

Caso negativo

Durante la carga de clientes, un archivo con un error en una fila llevó a una carga parcial: al final del día, la base de datos y la fuente externa estaban desincronizadas.

Ventajas:

Ahorro en la estructura del código, implementación simple Desventajas:
Pérdida de datos, lo que lleva a fallos en la lógica de negocio

Caso positivo

El archivo se verifica previamente en busca de errores, la inserción masiva se divide en porciones de 5000 filas, cada porción en su propia transacción. Se guardan registros de errores para análisis posterior.