Antwoord.

Geschiedenis van de vraag

De opkomst van grote opslagplaatsen en datastromen (ETL, migraties) vereiste niet alleen het laden van honderdduizenden rijen, maar ook de garantie dat de gegevens volledig worden geladen of helemaal niets. Dit wordt in SQL gerealiseerd door atomische bulkoperaties met behulp van transacties.

Probleem

Bij bulkinvoer is het risico op fouten groter - één onjuiste rij kan de hele invoer beschadigen of leiden tot gedeeltelijke invoer. Dit is onaanvaardbaar voor financiële, logistieke en andere kritische systemen.

Oplossing

De praktijk is om de bulkoperatie in een transactie te wikkelen, geschikte speciale commando's (BULK INSERT, COPY) te gebruiken en fouten te vangen/loggen. Belangrijk: bij een fout in een rij wordt de hele bulk teruggedraaid:

Voorbeeld voor 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;

In PostgreSQL (voorbeeld met COPY):

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

Belangrijke kenmerken:

Garantie van "alles of niets" (atomiciteit)
Hoge laadsnelheid door batchverwerking
Mogelijkheid om fouten te verwerken met registratie van probleemrijen

Misleidende vragen.

Heeft de grootte van de transactie bij Bulk Insert invloed op de prestaties en blokkeringen?

Ja, bij te grote volumes kan langdurige blokkering optreden, kan de transactie logfiles overbelasten en de server vertragen. Het beste is om in batches te laden (bijvoorbeeld 10.000 rijen per transactie).

Is Bulk Insert altijd standaard transactioneel in alle DBMS?

Nee, in sommige DBMS (zoals MySQL) is de bulk insert-commando niet altijd automatisch atomair - deze moet handmatig in BEGIN/COMMIT worden gewikkeld, anders is gedeeltelijke invoer mogelijk.

Kan de integriteit van externe sleutels worden gegarandeerd bij bulkinvoer?

Ja, maar alleen als de volgorde van invoer wordt gerespecteerd: eerst de ouder tabellen, dan de kind tabellen, of tijdelijk de beperkingen uitschakelen. Een fout in de buitenlandse sleutel zal de hele bulkinvoeringstransactie terugdraaien.

Typische fouten en anti-patterns

Proberen een te groot bestand in één operatie te laden, wat kan leiden tot geheugen- en logbestandenoverloop
Verwaarlozing van foutlogging - het is moeilijk om uit te zoeken waarom gegevens ongeldig zijn
Het schenden van de volgorde van invoer van gerelateerde tabellen met buitenlandse sleutels

Voorbeeld uit het leven

Negatieve case

Tijdens het laden van klanten leidde een bestand met een fout in één rij tot gedeeltelijke invoer - aan het einde van de dag waren de database en de externe bron niet meer gesynchroniseerd.

Voordelen:

Besparing op code-structuur, eenvoudige implementatie Nadelen:
Gegevensverlies, wat leidt tot storingen in de bedrijfslogica

Positieve case

Het bestand wordt vooraf gecontroleerd op fouten, de bulkinvoer is opgesplitst in porties van 5000 rijen, elke portie in zijn eigen transactie. Foutlogs worden bewaard voor verdere analyse.