0

2 つの問題があるストアド プロシージャがあります。

  1. 40個のパラメータがあります。最初のコメントは、40 個のパラメーターを持たないようにストアド プロシージャを再設計することになることを知っています。ただし、これは大きな条件セクションを持つ検索フォームです。そのため、ユーザーは検索のために最大 40 の異なる基準を指定しています。次に、これらの値をそれぞれパラメーターとして渡します。現在、40 パラメータの sproc があります。これらを XML パラメーターとして渡し、内部またはテーブル パラメーターで解析する方が効率的でしょうか (まだ SQL 2k5 を実行していますが、2k12 へのアップグレードを検討しています)。

  2. 3 つのパラメーターは、引用符とコンマで区切られた Guid 値の長い文字列です。基本的に、ユーザーには、時には何百もの製品ラインのリストが表示されます。次に、検索したいものをクリックします。文字列が長くなりすぎるという理由だけでチェックできる行数を制限しましたが、引用符とコンマで区切られた Guid の長い文字列を渡しています。これが正しい方法ではないことはわかっています。このような Guid 値の配列またはコレクションを渡すための標準の Trans SQl パターンは何でしょうか? これを行う40の3つの個別のフィールドがあります。これをより効率的に行い、現在の制限を超えて渡すことができるようにしたいと考えています。

4

2 に答える 2

0

1 つのストアド プロシージャで多くのことを達成しようとしているように思えます。検索アルゴリズムまたはクエリをより小さなピースに分割し、特定の検索エンティティの特定の結果を結果セットに照合しようとします。

可能な代替手段:

  • アプリケーション内で SQL クエリを動的に作成します。
  • プロシージャを複数の小さなプロシージャに分割し、検索条件に基づいて必要なものだけを呼び出します

私の正直な意見では、T-SQL で CSV を (手動で) 解析する必要があるのは、ほとんどの場合、コード/アーキテクチャの匂いです。

編集：読んでください... http://technet.microsoft.com/en-US/library/ms187926(v=sql.90).aspx

ストアド プロシージャは、最大 2,100 個のパラメーターを持つことができます。

だから問題は何ですか？なんらかの理由で限界に近づいていると思いました。より多くのパラメーターを使用するだけで、CSV を解析するよりもはるかに優れています。また、ストアド プロシージャ パラメータのデフォルト値を指定できることも忘れないでください。これにより、呼び出されるたびに 40 以上のパラメータすべてを指定する必要がなくなります。

また、テーブル値 UDF も忘れないでください...以下の方法で使用できるという点で非常に優れています

select * from dbo.fn_ProductsByLine('Toasters') pbl inner join dbo.fn_ProductsByPrice(10,20) pbp on pbl.productID = pbp.productID
于 2013-08-15T21:04:32.240 に答える