0

結合された列の 1 つが null 可能であるビューがありますが、多くの場合、2 つの行を区別する唯一の項目です。EF は、ビュー内のすべての非 null 項目から主キーを構築したことがわかります。ビューからプルすると、この null 許容列が常に正しく返されるとは限らないことに気付きました。これは、キーにマップする方法に関係しており、キーが表示された場合は同じ行が返されることを読みました。もう存在している。

理想的には、列を null 非許容にすることが最善の解決策ですが、より大きな問題を引き起こさずにそれを行うことはできません。

もう 1 つのアイデアはROW_NUMBER()、主キーを作成するために使用することでした。それが同様の問題を引き起こす可能性があるかどうかはわかりません（コンテキストが呼び出し間で更新されない場合、それは単にオフになるのでしょうか、それともクエリが異なることに気付くのに十分賢いのでしょうか？ORDER BY）関数とそれが行の動的順序付けにどのように影響するか。

パフォーマンスへの影響を最小限に抑えながら、すべての行が SQL クエリで表示されるとおりに正確に返されるようにする最善の方法は何ですか?

ありがとうございました..

例：

view: A int, B int, C int?

SQL Results:
1, 2, null
1, 3, 10
1, 3, 11

EF は次のようなものを返します。

1, 2, null
1, 3, 10
1, 3, 10

私もその11を取得する必要があります。

4

1 に答える 1

3

これは、ID マップ パターンが原因で発生します。既定では、EF は既に読み込まれているエンティティ (エンティティ キーによって識別される) を追跡します。結果セットに繰り返しエンティティ キーが含まれている場合、EF は既に読み込まれているエンティティと同じエンティティであると判断し、それらの新しいエンティティ インスタンスを作成しません。繰り返しレコード - 代わりに、そのキーを持つ最初のレコード用に作成されたインスタンスを使用します。これは、変更の追跡と、変更をデータベースに保存する機能のために必要です。

あなたの場合、これらのレコードはそれを行うために必要な情報を提供しないため、おそらく変更をデータベースに保存したくないでしょう。したがって、変更追跡なしでレコードをロードすると、ID マップ パターンがスキップされ、結果セット内のすべてのレコードに対して新しいエンティティ インスタンスが生成されます。

context.YourEntitySet.MergeOption = MergeOption.NoTracking; 
// Now execute your query
于 2012-04-30T08:50:26.087 に答える