多くのストアド プロシージャを持つ運用 SQL サーバー DB (レポート) があります。SP は、さまざまな方法で外部世界に公開されます
。SP に直接アクセスできるユーザーもいれば
、Web サービスを介して公開されるユーザーもいます
。また、DCOM レイヤーを介してインターフェイスとしてカプセル化されるユーザーもいます。
ユーザーベースは大きく、どのユーザーセットがどの方法で DB にアクセスするのか正確にはわかりません。
出力に 1 つの列を追加するか、既存の出力に列のグループを追加することによって、既存の SP を変更するというユーザー セットからの要求が頻繁に (隔月で約 1 回) あります。それ以外はすべて同じままです。
最初に、既存の SP を変更し、新しく要求された列を出力の最後に追加することから始めました。しかし、これにより他のユーザー ベースによって作成されたカスタム ツールが機能しなくなりました。そのツールには列の数がハードコーディングされていたため、列を追加するとツールも変更する必要があったためです。
また、一部の列では、その列をレポートに取り込むために複雑なロジックが必要であり、SP のパフォーマンスが低下し、すべてのユーザー (新しい列を必要としないユーザーも含む) に影響を与えました。
これを修正するためのさまざまな方法を考えています。
1 フローを制御するためのデフォルト パラメータ
コード パスを制御するデフォルト パラメータとしてフラグを追加することで、既存の SP を更新し、新しい機能を制御します。パラメータの値が true に設定されている場合、デフォルトのパラメータを使用して、新しい機能のみを呼び出します。デフォルトでは、False に設定されています。
アドバンテージ
- 新しいオブジェクトは必要ありません。
- 進行中のメンテナンスは影響を受けません。
- テストのオーバーヘッドは引き続き制御されます。
不利益
- 既存の SP が変更されるため、既存の機能と新しい機能のテストが必要になります。
- クライアント ツールがどのように SP を呼び出しているかについては何もわかっていないため、何も壊れていないことを確信することはできません。
- より多くのリクエストで同じレポートが再度変更された場合、処理が難しくなります。つまり、フラグが増え、コードが判読できなくなります。
2 新しいストアド プロシージャ
SP の署名 (入力/出力) を変更する要件に対して、新しいストアド プロシージャが作成されます。
新しい SP は、既存のものに対して元のストアド プロシージャを呼び出し、その上に新しい要件のロジックを追加します。
アドバンテージ
- ここでの利点は、既存の手順に影響がないため、古いロジックのテストが不要になることです。
不利益
- 変更が要求されるたびに、データベースに新しいオブジェクトを作成する必要があります。これは、データベース メンテナンスのオーバーヘッドになります。
新しいパラメーターの追加に基づいて実行計画は変更されますか? はいの場合、これは、新しい列を要求しなかったユーザーに悪影響を与える可能性があります。
SP は DB へのパブリック インターフェイスであり、インターフェイスは不変である必要があると考えると、オプション 2 を使用する必要がありますか?
ベスト プラクティスは何ですか、それともケースバイケースで異なりますか?また、オプションを選択する際の主な要因は何ですか?
前もって感謝します！