4

ファイルに書き出す一連のデータを作成しようとしています。これは基本的に、さまざまなテーブルのさまざまなフィールドで構成されたレポートです。いくつかの列では処理を行う必要があり、いくつかの列では選ばれるだけ。

異なるユーザーは、特定の列に対して異なる処理を実行することを希望する可能性が高く、将来的には、計算列用の関数を追加する必要があるでしょう。

これらの計算列に必要になる可能性が高いさまざまな関数をすべて格納して使用するための、最もクリーンで柔軟なアプローチを検討しています。私が見逃している明らかな解決策。

単純で少し変わった例として、Staff テーブルがあります。

Employee |    DOB           |   VacationDays
Frank    |    01/01/1970    |   25
Mike     |    03/03/1975    |   24
Dave     |    05/02/1980    |   30

私は次のようなクエリになってしまうと思っています

SELECT NameFunction(Employee, optionID),
       DOBFunction(DOB, optionID),
       VacationFunction(VacationDays, optionID),
from Employee

ユーザー定義関数では、関数内の case ステートメントで optionID を使用して、実行する処理を決定します。

または、他の関数のルックアップ テーブルを使用して、データが返される方法をカスタマイズ可能にしたいと思います。

ID  |    Name                  |   Description
1   |    ShortName             |   Obtains 3 letter abbreviation of employee name
2   |    LongDOB               |   Returns DOB in format ~ 1st January 1970
3   |    TimeStampDOB          |   Returns Timestamp for DOB
4   |    VacationSeconds       |   Returns Seconds of vaction time
5   |    VacationBusinessHours |   Returns number of business hours of vacation

どちらがきれいに見えますが、おそらく動的 SQL を使用してクエリを作成する方法がわかりません。賢明な代替手段はありますか？

関数は数千行で使用されます。

私が見つけた最も近い答えは、このスレッドでした: Call dynamic function name in SQL

私は動的 SQL の大ファンではありませんが、この場合、求めている結果を得るための最良の方法ではないでしょうか?

返信ありがとうございます、ありがとう、クリス

4

3 に答える 3

1

最終的には、どちらか早い方を使用する必要があるため、両方の方法 (および誰かが考え出す他の方法) を試してから決定する必要があります。

関数にテーブルへの余分な選択がない限り、最初のオプションの方が好きです。ユーザー定義関数が別のレポートで再利用されない場合、ユーザー定義関数は必要ないかもしれません。

動的順序付けの追加や複雑な WHERE 条件の追加/削除など、クエリのパフォーマンスを向上させるためにのみ動的 SQL を使用することを好みます。

しかし、これらはすべて主観的な意見です。最良の方法は、試して比較して決定することです。

于 2012-05-30T11:21:34.157 に答える
1

実際、これはどちらが速いかという問題ではありません。特に新しい機能 (新しい列、新しい列形式、それらの並べ替え) を追加するために、コードをよりきれいにするものは何かという問題です。

2 番目のアプローチを「動的 SQL を使用する」と考えないでください。否定的な意味合いを持つ傾向があるためです。代わりに、データ駆動型のアプローチと考えてください。ユーザーが取得できる列と形式を説明する表を作成したいと考えています。これは素晴らしい！その後、ユーザーは列のリストを提供できます。ユーザーからの情報とメタデータ テーブルの情報を組み合わせて、目的の結果を生成する魔法のストアド プロシージャが作成されます。

私はデータ駆動型アプローチの大ファンであり、動的 SQL は、それらを実装するためにこれまでに見つけた最高の SQL ツールです。

于 2012-05-30T13:19:18.853 に答える
1

私は2番目の解決策に行きます。ルックアップ テーブルで実際のストアド プロシージャ名を使用することもできます。

create proc ShortName (
    @param varchar(50)
)as
begin
    select 'ShortName: ' + @param
end
go

declare @proc sysname = 'ShortName'

exec @proc 'David'

上記の例でわかるように、exec の最初のパラメーター (つまり、プロシージャー名) をパラメーターにすることができます。これは、動的SQLに関するすべての通常の警告で述べました...

于 2012-05-30T10:39:25.323 に答える