これは、直接的な質問と議論のポイントの両方になります。最初に直接質問します。
ストアドプロシージャは別のストアドプロシージャを動的に作成できますか？（個人的にはSQL Server 2008に興味がありますが、より幅広い議論のために、SQL Server 2008は開いたままにしておきます）
今私が尋ねている理由に。簡単に言うと（詳細は他の場所で読むことができます）、SQLServerのユーザー定義スカラー関数はせいぜいパフォーマンスのボトルネックです。コードベースでクエリ全体の速度を3〜4倍遅くする使用法を見てきましたが、私が読んだところによると、S-UDFのローカルな影響は10倍以上になる可能性があります
ただし、UDFは、抽象化レベルの向上、面倒なボイラープレートの削減、ロジックルールの集中化などに最適です。ほとんどの場合、UDFは、インラインで簡単に拡張できる単純な式に要約されますが、そうではありません（私は本当に非クエリ関数（文字列操作など）のみを考えます。これについては、MSからの賛同を得て、将来のリリースで対処されるバグレポートを見てきました。しかし今のところ、私たちは（IMHO）壊れた実装に耐えなければなりません。
回避策の1つは、代わりにテーブル値UDFを使用することです。ただし、これらは、常に処理したくない方法でクライアントコードを複雑にします（特に、UDFが式の結果を計算する場合）。
したがって、私のクレイジーなアイデアは、最初は、Cプリプロセッサディレクティブを使用してプロシージャを記述し、それをプリプロセッサに渡してからRDBMSに送信することでした。これは機能する可能性がありますが、独自の問題があります。
それが私の次のクレイジーなアイデアにつながりました。それは、DB自体に「マクロ」を定義し、マクロを含む未処理のSPを含む文字列を受け入れ、マクロをインラインで展開してからRDMSに送信するマスタープロシージャを用意することでした。 。これはSPが得意なことではありませんが、最初にこれを実行できると仮定すると、機能する可能性があると思います。したがって、私の最初の質問です。
しかし、これで質問への道を説明したので、他のアイデアのためにそれを開いたままにしておきたいと思います。これらの方針に沿って考えてきたのは私だけではないと確信しています。おそらく、サードパーティのソリューションがすでに存在しているのでしょうか。私のグーグルはまだあまり現れていません。また、楽しいディスカッショントピックになると思いました。
[編集]
私の研究で見つけたこのブログ投稿は、私が見ているのと同じ問題について説明しています。私やブログのポスターが、オーバーヘッドにつながる間違ったことを誰かが指摘してくれたら嬉しいです。
また、S-UDFでWITH SCHEMABINDINGを使用していることも付け加えておきますが、それは私に何の利点も与えていないようです。