現在、DBに依存しないORMに依存する自作のエンティティフレームワークがあります。
約150個のExcelテンプレート（セルの位置、セルの種類、フォーマットなどの情報を含む）のメタデータをDBにバッチロードするソフトウェアを構築する必要があります。
操作できます
SQLバッチ経由（高速ですがインタラクティブ性が低い）
メモリ内にオブジェクトを構築し、さまざまな整合性チェックのためにLINQクエリでオブジェクトを処理してから、DBに変更をコミットする
SQLの方が絶対に速いことは知っていますが、知っていると思います...どれくらい速いのでしょうか。
詳細には、SQLクエリはLINQクエリよりもどれくらい高速ですか（必要なすべてのデータがORMによってメモリにすでにロードされていると仮定します）？
ほとんどの場合、TBHはlinqまたはSQLが正確に問題になるわけではありません。パフォーマンスは、挿入するデータの量、現在テーブルにあるデータの量、および維持しているインデックスに関連します。
次に、データの複数の列にわたってクロスチェックや整合性チェックを行う必要があるかどうか。断片化が悪く、アルゴリズムがないために、インデックスを追加してテーブルを再構築すると、挿入時間が数分から数ミリ秒に短縮される状況がありました。
Linqは、挿入および変更ロジック用のSQLを生成する効果的な方法です。ただし、常に次のパターンになります。
挿入で利用できるロジックがある場合は、setロジックを使用してSQLで更新を行うことができる場合があります。たとえば、Update Customers Set KeyCustomer = 1 where Sales> 1000000. SQL Serverは、このようなコマンドを、ORMで実行できるよりも数千倍速く処理します。ただし、@ gbnがすでに正しく指摘しているように、強力なSQLコーダーでいっぱいのチームがいない限り、メンテナンスは短期的にはパフォーマンスの向上よりも優先されることがよくあります。
かなりの数のレコードを挿入する必要がある場合は、SSISを介したバッチ読み込みやETLを実際に検討する必要があります。これらのAPIは、よりスマートなアルゴリズムを使用し、挿入ごとではなくバッチで制約チェックを実行するため、パフォーマンスが大幅に向上します。ただし、SSISパッケージの管理は、アプリのボタンをクリックするよりもはるかに手間がかかります。これらはすべて、アプリケーションを設計するときに考慮する必要のある設計上の決定です。
ここでは、さまざまなORMと次のパフォーマンスの比較を示しますSqlDataReader：http ：//code.google.com/p/dapper-dot-net/ （パフォーマンスセクション）。LINQクエリをコンパイルすると、パフォーマンスが大幅に向上する可能性があることに注意してください。http: //www.codeproject.com/Articles/38174/How-to-improve-your-LINQ-query-performance-by-5-X