0

大規模なスイート内に多数のモジュールがあり、それらはすべて共通のストアド プロシージャと関数のセットを使用します。これは主に、それらがすべて共通のデータとテーブルのセットを使用するという事実によるものです。このアプローチにより、同じ呼び出しを行ったときにすべてのモジュールが同じ応答を受け取ることが保証されます。これは非常に良いことです (特に金融業界では)。

ただし、このアプローチの欠点は、共有ストアド プロシージャまたは関数の 1 つを変更する必要があるスイート内の 1 つのモジュールを更新すると、ほぼスイート全体を更新する必要があることです。時間とコストの点でこれは悪いことです。

管理の複雑さを最小限に抑えながら、単一のストアド プロシージャを更新するたびに、このスイートのアップグレードの問題を軽減するためにどのような戦略を採用できるでしょうか。

これは、Microsoft が DLL(s) / API(s) で抱えていたバージョンの問題に似ています。この問題では、API でシグネチャの変更が見られ、xxx2 バージョンが必要になります。これは理想的な原因ではありません。基本的に 2 つのバージョンがあり、同期が取れなくなる可能性があるため、両方を維持およびアップグレードする必要があります (つまり、同じ質問に対する 2 つの異なる回答)。

この点に関する戦略やベストプラクティスは大歓迎です。

前もって感謝します。

ワティ

4

1 に答える 1

0

2つの戦略は、ビューとストアドプロシージャです。

ビューを使用して、テーブル内のデータにアクセスします。このようにして、基礎となるテーブルを（1つのモジュールに対して）変更でき、他のモジュールをすぐに変更する必要はありません。最終的には、そのモジュールの変更にも取り掛かることができます。たとえば、1つのモジュールに対して1つのテーブルを2つの異なるテーブルに分割する場合があります。他のモジュールはビューにアクセスするため、気付くことはありません。ビューを変更するだけで元のデータが返されます。

select *これらの行に沿って、列、名前、または順序が変更される可能性があるため、を使用することは絶対に避けてください。

insert2番目の戦略は、すべての、、updateおよびdeleteをストアドプロシージャにラップすることです。これには、プロシージャでチェック、ロギング、および通知を実行できるという2番目の利点があります。トリガーと制約を使用してこれを模倣することもできますが、ストアドプロシージャのアプローチの方がはるかに保守しやすいと思います。

于 2013-03-23T21:12:40.987 に答える