1

私は現在、サブクエリ内にあるIDに基づいて結果をフィルタリングするMultiCriteriaクエリを持っています

Subqueries.PropertyIn("Id", detachedCriteria)

サブクエリは、多基準クエリで使用されるすべてのクエリで同じです。

私の現在のケースでは15回、サブクエリが繰り返されているSQLを見ると少し醜いようです。

個別のクエリの理由は、それぞれが異なる結合を持ち、1つの大規模なデカルト結合を望まないためです。

手作業でSQLを記述している場合は、繰り返されるサブクエリを共通のテーブル式に引き出します。

WITH XYZ AS
{
    ....
}

次に、サブクエリは15個のクエリのXYZのwhereidになります。

これは少しSQLサーバー固有であり、代替は一時テーブルまたは他のデータベース固有の機能です。

クエリを改善する方法についてのアイデアはありますか、それともサブクエリが複製されたままになっていますか？

4

1 に答える 1

1

ええと、複数の結果セットを返す場合、それは単一のステートメントWITHにしか適用できないので、とにかく使用は役に立ちません。SELECT

いずれにせよ、データレイヤーコードをデータベースに依存しないようにするために、おそらく実際のクエリロジックをストアドプロシージャに押し込みます。これは、エンジン固有の機能を使用して町に行くことができることを意味します。これは、すべてがパブリックインターフェイスの背後に隠されているためです。はい、サポートするデータベースエンジンごとにクエリを再実装する必要があります（通常は非常に少ないです）が、各エンジンで実行されるものを完全に制御でき、データアクセスコードは非常にクリーンになります。

于 2010-11-15T02:41:41.823 に答える