2

私たちが現在構築しているものの 1 つは、人を探すための検索機能です。

簡単に始めるときは、次のように Linq を使用してエンティティを検索しました。Entities.People.Where(z=>z.Birthdate < birthdate).ToList()

その後、新しい検索基準が追加されると、linq ステートメントはどんどん大きくなり、誰も理解できなくなったのでリファクタリングする必要があります。

この時点で、「ここで働いていましたか」、「この言語を話せますか」、「これらの 6 つのスキルのうち、どのスキルを習得していますか」など、8 つの関連項目の検索を容易にする必要があります。

これらのアイテムはすべて、SqlServer では 1:N または N:N の関係であり、複数のアイテムを検索しており、「どれだけ一致しているか」を知りたいと考えています。

例: フランス語または英語またはドイツ語を話す人を探し、少なくとも 1 つの一致を持っているすべての人を取得したい。それらの人々について、一致する数を知りたい (つまり、3 人中 1 人または3分の2）すべての人が持っています。

この時点での問題は、何をするのが賢明かということです (データベース内の約 10.000 人)。

ブレーンストーミングの結果、次の選択肢にたどり着きました。

  1. データベースで最速の検索を行い (限られた量のレコードを取得するため)、コードで残りを並べ替えます
  2. Linq で構築を続ける
  3. SqlServer でアクション全体を実行する

始めるためのヒントはありますか？

4

2 に答える 2

1

Linq to Entities 式が複雑になりすぎた場合、それは要件がかなり急速に進化していることを意味します。

データベースの合計サイズが小さい場合 (10,000 レコードはかなり小さい)、一致する可能性のあるすべての人を返す SQL (または Linq to Entities) ステートメントを記述し、ビジネス レイヤーで並べ替えを適用するのが最も効率的であることがわかります。 .

私が「効率的」と言うのは、データベース側でいくつかのレコードをフィルタリングしないことで多くを失うことはないためです (DB に 10M レコードが含まれていて、かなりの部分を返した場合、それはあまり真実ではありません)。チームがコードで作業するのがより快適になるかもしれないという質問を書きます。

于 2012-10-30T15:36:31.660 に答える
1

速度に関する限り、コンパイルされたクエリを使用している限り、selectパフォーマンスが大きく異なることはほとんどありません。Rico Marianiによる素晴らしい記事があり、SQL に関して LINQ を高速化するために行ったすべてのことを詳しく説明しています。パンチラインは、コンパイルされた select ステートメントを使用している場合 (本来あるべきように)、ストアド プロシージャとほぼ同じ速度で実行されていることです。実際には、生の SQL よりも 93% 高速です。コンパイルされた選択を使用していない場合は、この記事を読んで、それらを作成する方法についての洞察を得る必要があります。コンパイルされていない選択クエリは、通常の SQL の約半分の速度であるため、大幅に向上する可能性があります。

速度がそれほど問題ではなく、この複雑に聞こえるデータベース スキーマを維持するという組織のタスクについて言及している場合、それはまったく別のことです。その場合は、SQL レベルから開始して、少なくとも必要なすべての一致があることを確認することをお勧めします。これは簡単にテストでき、SQL はその種の検索用に最適化されています。また、シナリオをテストするためにプログラムをコンパイルして実行するのではなく、サーバーから多かれ少なかれ即時のフィードバックを得ることができれば、作業の確認が容易になります。

必要なものがすべて揃っていて、不要なものがないことを確認したら、候補の優先順位付けに関するルールを使用して、C# で単純に整理するという、はるかに小さなタスクを処理できます。

編集：おっと、エリックが私のものと非常によく似た答えを持っているとは思いませんでした。しかたがない。

于 2012-10-30T15:51:49.907 に答える