回答。

質問の背景

大規模なストレージとデータストリームの出現（ETL、マイグレーション）は、何万行もロードするだけでなく、データが完全にロードされるか、何もロードされないことを保証する必要があります。SQLでは、トランザクションを使用して原子的なバルク操作を実現します。

問題

バルク挿入を行う際、エラーのリスクが高く、1つの不正な行が全体のロードを破損させたり、部分的な挿入を引き起こす可能性があります。これは、金融、物流、その他の批判的なシステムには許容できません。

解決策

実践として、バルク操作をトランザクションにラップし、適切な特別なコマンド（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;

重要な特徴：

「すべてか無か」の保証（原子性）
バッチ処理による高速なロード
問題のある行を記録してエラーを処理する機能

トリッキーな質問。

バルク挿入におけるトランザクションのサイズはパフォーマンスやロックに影響しますか？

はい、あまりにも大きな量の場合、長時間のロックが発生し、トランザクションログが溢れ、サーバーが遅くなる可能性があります。最良の方法は、バッチでロードすること、たとえば1トランザクションあたり10,000行です。

バルク挿入はすべてのDBMSで常にデフォルトでトランザクショナルですか？

いいえ、一部のDBMS（たとえばMySQL）では、バルク挿入コマンドは常に自動的に原子的ではなく、手動でBEGIN/COMMITでラップする必要があります。そうしないと、部分的なロードが発生する可能性があります。

バルク挿入時に外部キーの整合性を保証できますか？

はい、ロード順序が守られている場合のみ：まず親テーブル、その後子テーブル、または一時的に制約を無効にします。外部キーのエラーは、バルク挿入の全トランザクションをロールバックします。

一般的なエラーとアンチパターン

1回の操作であまりにも大きなファイルをロードしようとすること、これがメモリとログファイルを溢れさせる
エラーログを無視すること — データが不正な理由を特定するのが難しい
外部キーを持つ関連テーブルのロード順序を守らない

具体例

ネガティブケース

クライアントのロード中に、1行にエラーのあるファイルが部分的なロードを引き起こし、日の終わりにはデータベースと外部ソースが非同期になった。

長所:

コード構造の節約、簡単な実装 短所:
ビジネスロジックの障害を引き起こすデータ喪失

ポジティブケース

ファイルは事前にエラーがないかチェックされ、バルク挿入は1回5,000行のバッチに分割され、各バッチはそれぞれのトランザクションで処理されます。エラーログは後の分析のために保存されます。