0

NHibernate を介してマップされたときに、完全なユーザーの詳細を含む関連データの大規模な階層を構築するメインの User テーブルがありますが、これはほとんど必要ないため、常にロードする必要はありません。私は UserLight と呼ばれる部分的なテーブルを持っています。これには非常に基本的な情報のみが含まれており、基本的な情報にすばやくアクセスする必要があるため、階層的な結合やコレクションは含まれていません。

しかし、私の質問はそれらとは別に、それは単なる背景です.

私の Web サイトでは、大規模なユーザーベースから他のユーザーを検索する必要があり、検索からユーザーを削除する機能を提供したいと考えています。つまり、ユーザー プロファイルの X をクリックすると、今後の検索では表示されない削除のリストに追加されます。

別のテーブルと UserSearchRemoval という名前のオブジェクト マッピングを作成し、データ列として UserId、RemovedId のみを使用しました。

応答性を高くしたいので、コードからこれを操作する最良の方法を見つけようとしています。GUI に関する最善の方法は、Web サービスを呼び出す Web 側で Ajax クエリを呼び出し、2 つのユーザー ID を渡して、データベース レベルで作業を行うことだと思います。

私が確信していないのは、DB レベルでこれを行う最善の方法です。基本的なレベルでは、検索の削除が既に存在するかどうかを確認するだけで (時間がかかります)、存在しない場合は追加するか、チェックせずに追加して重複をリスクにさらすことができます。最もクリーンなソリューション。したがって、追加するだけが最速の方法のようです。

ユーザーの削除のセッションレベルのリストを維持し、それに追加してNHibernateに残りをさせることで、これを行うことができる別の方法はありますか? これは、セッション レベルで大量のデータを保持することによって悪いように思えます。メモリ内のコレクションを更新してそれを db オブジェクトに転送する作業は、DB に単一の行を追加するよりもはるかに遅くなるように思えます。

誰でもより良い解決策を考えることができますか?

ありがとう

4

1 に答える 1

0

答えは、ユーザー データベースの相対的なサイズ、平均的な検索結果、平均的なブロック リストによって異なります。また、ブロック ルールが今後より複雑にならないようにする方法にも依存するため、ブロック ルールを DB レベルで安全に含めることができます。

ユーザー データベースが 500,000 ユーザー、平均検索結果が 500、平均ブロック リストが 100 であり、ルールが進化する可能性があると仮定すると、辞書ベースの検索後アプリケーション レベル フィルタリングを選択します。

于 2012-12-07T09:24:07.547 に答える