2

Entity Framework 5 Code Firstアプローチを使用して、MS-AccessデータベースをSQL ServerCompact4.0に移行しています。データベースで生成された整数IDの使用は非常に遅く、さらに悪いことに、データベースのサイズに応じて遅延が指数関数的に増加することがわかりました。これにより、Identity列を使用できなくなり、エンティティフレームワークと組み合わせたSQL ServerCompact4.0でこの機能の実装が不適切になっているようです。

そこで、いくつかのテストを実行したところ、クライアント側で生成されたキーを使用すると、挿入が少なくとも20倍速くなり、挿入の指数関数的な増加がなくなることがわかりました。

現在、クライアント側のIDを生成するための最良の方法を検討しています。GUIDを使用するのが最も安全なオプションのようですが、これは読み取りアクションに悪影響を与えることを私は読みました。クライアント側で生成される自動インクリメントされた整数を使用する戦略はありますか？

編集：私はさらに質問につながる根本的な問題を調査します。それまでの間、私の本当の質問に答えてもらえますか？:-)

EDIT2：EFおよびSQL ServerCompact4.0で自動IDを使用するのが非常に遅いという主張を誰も信じていないように思われるのはかなり腹立たしいことです。これについては、簡単に再現できる概念実証とともに、別の質問を投稿しました。

4

3 に答える 3

1

EFを使用して大量のデータを移動している場合は、それが間違っています。代わりにADO.NETを使用し、たとえばBULK COPYアプローチを使用します（SQL CEではSqlCeUpdateableRecordを使用します）。私のSqlCeBulkCopyライブラリを使用して、コーディングの手間を省くことができます。

于 2013-02-07T07:36:15.367 に答える
1

ID生成の方法がパフォーマンスの問題の原因であるとは思いません。
移行プロセス中、変換プロセスの前にパフォーマンスを向上させたい場合は、メインテーブルの主キーと外部キーおよびその他の制約を無効にできると思います。（これはスクリプトまたは手動で行うことができます）
ただし、データの整合性が新しい懸念事項であり、変換コードは強力である必要があるため、変換プロセスの後で、制約を有効にすることができます。
お役に立てれば。

于 2013-02-10T19:20:50.137 に答える
0

私が見ている解決策。

a）パフォーマンスの問題を修正してみてください。私の提案（コンテキスト内で多数のエンティティを使用しないでください）は、ビジネス上の問題が許す限り少なくしてみてください。マージトラッキングなどを使用しないでください...EFパフォーマンスのヒントを参照してください。 http://blogs.msdn.com/b/wriju/archive/2011/03/15/ado-net-entity-framework-performance-tips.aspx および http://msdn.microsoft.com/en-au/ library / cc853327.aspx

b）GUIDを使用します。外部に割り当てる（順次ではありませんが、高速です）

c）メモリ内で実行され、一度に多くのキーを割り当て、現在の状態を維持できるカスタマー整数ジェネレーターを使用します。この手法はSAPで使用されています。彼らはそれを「番号範囲」と呼んでいます。非常に高速にすることができますが、b）ほど高速ではありません。

ところで、部分的なDBコピーと移行を簡単/簡単にするために、DBで生成されたIDではなくGUIDを使用しています。:-)

于 2013-02-11T15:06:20.627 に答える