Odpowiedź.

Historia pytania

Pojawienie się dużych magazynów i strumieni danych (ETL, migracje) wymagało nie tylko załadowania setek tysięcy wierszy, ale również zapewnienia, że dane zostaną załadowane w całości lub nie załadowany zostanie nic. W SQL realizuje się to poprzez atomowe operacje masowe za pomocą transakcji.

Problem

Podczas masowego wstawiania (Bulk Insert) ryzyko błędu jest wyższe — jeden niepoprawny wiersz może zepsuć całe załadowanie lub prowadzić do częściowego wstawienia. Jest to niedopuszczalne w systemach finansowych, logistycznych i innych krytycznych systemach.

Rozwiązanie

Praktyka — otaczać operację masową w transakcji, używać odpowiednich specjalnych poleceń (BULK INSERT, COPY) oraz łapać/logować błędy. Ważne: w przypadku błędu któregokolwiek wiersza następuje wycofanie całego bloku:

Przykład dla 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;

W PostgreSQL (przykład z COPY):

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

Kluczowe cechy:

Gwarancja „wszystko lub nic” (atomicity)
Wysoka prędkość ładowania dzięki przetwarzaniu wsadowemu
Możliwość obsługi błędów z zapisem problematycznych wierszy

Pytania z pułapką.

Czy rozmiar transakcji podczas Bulk Insert wpływa na wydajność i blokady?

Tak, przy zbyt dużych objętościach można uzyskać długotrwałą blokadę, przepełnić logi transakcji i spowolnić serwer. Najlepszym rozwiązaniem jest ładowanie w porcjach (batch), na przykład po 10000 wierszy na transakcję.

Czy Bulk Insert jest zawsze transakcyjny domyślnie we wszystkich DBMS?

Nie, w niektórych DBMS (np. MySQL) polecenie bulk insert nie zawsze jest automatycznie atomowe — wymaga owinięcia go w BEGIN/COMMIT ręcznie, w przeciwnym razie może wystąpić częściowe załadowanie.

Czy można zapewnić integralność kluczy obcych przy masowym wstawianiu?

Tak, tylko jeśli kolejność ładowania jest przestrzegana: najpierw tabele rodzicielskie, a potem dziecięce, lub tymczasowe wyłączenie ograniczeń. Błąd klucza obcego wycofa całą transakcję bulk insert.

Typowe błędy i antywzorce

Próba załadowania zbyt dużego pliku w jednej operacji, prowadząca do przepełnienia pamięci i plików logów
Lekceważenie logowania błędów — trudno ustalić, dlaczego dane są niepoprawne
Naruszenie kolejności ładowania powiązanych tabel z kluczami obcymi

Przykład z życia

Negatywny przypadek

Podczas ładowania klientów plik z błędem w jednym wierszu spowodował częściowe załadowanie — do końca dnia baza danych i zewnętrzne źródło były niesynchronizowane.

Zalety:

Oszczędność na strukturze kodu, łatwa realizacja Wady:
Utrata danych, prowadząca do awarii w logice biznesowej

Pozytywny przypadek

Plik jest wstępnie sprawdzany pod kątem błędów, Bulk insert jest podzielony na porcje po 5000 wierszy, każda porcja w swojej transakcji. Logi błędów są przechowywane do dalszej analizy.