2012-03-27 3 views
2

データベースに行を挿入し、別のスレッドでそれらの行を読み込み、それら)。.netでSQL Serverデータベースにデータを書き込んだり、読み込んだり、削除したり(更新しない)、最も効果的な方法

通常、私はこのためにEntity Frameworkを抜き出すだけです。しかし、私はこれが速いことが必要です。本当に速い。

行は、bigint,bigintおよびvarchar(max)となります。

Entity Frameworkの方が速いのですか?もしそうなら、それは何ですか?

(Iは、SQL Server 2008 R2に対してつもりです)

+1

datareaderより速いものはありません。あなたは複数のスレッドがあるので、汚れた読み込みを行うつもりですか? – SQLMason

+0

FWIW、SOは[Dapper](http://code.google.com/p/dapper-dot-net/)を使用しています。 – jrummell

答えて

5

この程度Dapper ORMページでいくつかの良い情報があります。

セクションを参照してください。500回以上の反復--POCOシリアル化以下のSELECTマッピングのパフォーマンスを参照してください。それはSELECTだけを議論しますが、あなたはこれをある程度まで推論することができます。

たとえば、Entity Frameworkはクエリの速度に関しては最悪の方法です。

Method        Duration Remarks 
Hand coded (using a SqlDataReader) 47ms 
Dapper ExecuteMapperQuery<Post> 49ms 
ServiceStack.OrmLite (QueryById) 50ms 
PetaPoco       52ms  Can be faster 
BLToolkit       80ms 
SubSonic CodingHorror    107ms 
NHibernate SQL      104ms 
Linq 2 SQL ExecuteQuery   181ms 
Entity framework ExecuteStoreQuery 631ms 
+0

私はEF期間に少し驚いていますが、完全にはショックを受けていません。あなたは「あなたのためにもっと」を得るが、それは著しく遅い。 – SQLMason

5

Raw ADO.NETが最も高速ですが、私はDapperをマイクロORMとして選択します。それは驚くほど速く、開発に多くの手助けをします。

しかし、ダッパーなどが最も速い理由の主な原因は、コントロールであるため、パフォーマンスの高いSQLクエリを慎重に作成できることが重要です。

あなたは何かを必要とすること以外に、データアクセス技術について多くのことを考える必要はありません。実際のSQLに近づき、あまりにも多くの抽象化を強制しません。 データベース、インデックスレイアウト、トランザクション処理、およびクエリの最適化について考えてください。そこでは、パフォーマンスの主要な向上が見られます。