多くのアプリケーションがアクセスするデータベースでストアド プロシージャを使用する人々のアプローチに興味があります。具体的には、アプリケーションごとに異なる一連のストアド プロシージャを維持する傾向がありますか、共有セットを使用しようとしますか、それとも混合しますか?
一方では、SP の再利用により、モデル変更などの場合に変更が少なくなり、理想的にはメンテナンスが少なくて済みます。一方、アプリケーションのニーズが異なる場合、1 つのアプリケーションのストアド プロシージャを変更すると、他のアプリケーションが壊れる可能性があります。私たちの環境では、各アプリケーションに独自の開発チームがあり、それらの間のコミュニケーションが不十分であることに注意してください。ただし、データ チームのコミュニケーションは良好で、主にストアド プロシージャの作成を担当しています。
ありがとう！
ストアドプロシージャは、要求を行うアプリケーションではなく、返す予定のデータに基づいて作成する必要があります。GetAllItemsであるストアドプロシージャがある場合は、データベース内のすべてのアイテムを返す必要があります。アプリケーションの1つですべてのアイテムをカテゴリ別に取得する場合は、GetAllItemsByCategoryを作成します。データを要求するアプリケーションに基づいてストアドプロシージャのビジネスルールが変更される理由はありません。
私の経験では、SP を複数のアプリケーションで共有することは苦痛の原因です。実際、複数のアプリケーションから直接アクセスされるデータベースを持つことは、最良の長期的なアーキテクチャではないと私は主張します。
私が推奨し、実装したパターンは、1 つのアプリケーションのみが各データベースを「所有」し、他のアプリケーションがデータにアクセスして変更するための API (サービスなど) を提供するというものです。
これにはいくつかの利点があります。
ストアド プロシージャは、それを使用するアプリケーションに応じて変更されないビジネス ルールを公開する必要があります。これにより、ルールが使用されるすべての場所ではなく、一度だけルールを保存して更新することができます。これは悪夢です。
このように考えてください。ストアド プロシージャは、その下にあるデータに関するものであり、その上にあるアプリケーションについて実際に認識すべきではありません。あるアプリケーションでは、別のアプリケーションでは必要のない方法でデータの読み取りまたは更新が必要になる可能性があります。
それが私のアプリケーション/データベース/などであり、あるアプリケーションを改善するための SP への変更が別のアプリケーションを壊した場合、より深い設計上の問題の証拠と見なします。
あなたの質問の最後の部分は、それ自体で答えたと思います。
すでに十分なコミュニケーションが取れていない状態で、開発チーム間で手順を共有すると、潜在的な障害点が増えるだけであり、いずれかのチームが苦労する可能性があります。
私が複数のプロジェクトに取り組んでいる同じチームに所属している場合、時間を節約し、手順を共有しますが、通常、少し重複する (あちこちでいくつかの手順を行う) と、アプリケーションが後で必要になる壊滅的な変更/重複を回避するのに役立つことがわかりました。発散し始めます。
また、LordScarlet は重要な要素についても指摘しています。それがビジネス ロジックを共有しない一般的なものであれば、問題にはならないはずです。
複数のアプリケーションに共通のストアド プロシージャがある場合は常に、それらのプロシージャ (およびビューやテーブルなど) のためだけにデータベースを作成します。そのデータベース (「ベース」と名付けました) には、そのデータベース (メンテナンスとテスト) を担当する開発者 (またはチーム) がいます。
別のチームが新しい機能を必要とする場合、彼らはそれを書くことができ、基本開発者はそれを基本 DB に実装するか、より簡単な方法を提案します。
それはすべて、抽象化戦略に依存します。ストアド プロシージャは抽象化の個別のポイントとして扱われますか、それともそれらを呼び出すアプリケーションの別の部分として扱われますか。
それに対する答えは、それらを管理する方法を教えてくれます。それらが個別の抽象化である場合、新しい機能が必要であるかのように共有でき、新しいプロシージャを追加します。それらを呼び出すアプリの一部である場合は、共有しないでください。
可能な限り単一の共有ストアド プロシージャを使用しようとしていますが、あなたが説明した状況にも遭遇しました。これは、ストアド プロシージャ (ApplicationName_StoredProcName) にアプリケーション プレフィックスを追加することで処理しました。
多くの場合、これらのストアド プロシージャは、集中型または「マスター」のストアド プロシージャを呼び出しますが、この方法では、後でアプリ固有の変更を行う余地が残されています。
多くのストアドプロシージャはアプリケーションに依存しませんが、アプリケーションに依存するものもあります。たとえば、CRUD（作成、選択、更新、削除）ストアドプロシージャは、アプリケーション間を移動できます。特に、監査ロジックを投入できます（トリガーで実行されることもありますが、トリガーで取得できる複雑さには制限があります）。ソフトウェアショップにある種の標準アーキテクチャがある場合、アプリケーションに関係なく、中間層でデータベースを作成/選択/更新/削除するためのストアドプロシージャが必要になる場合があります。その場合、プロシージャは共有されます。
同時に、データを表示するためのいくつかの便利な方法、つまりGetProductsSoldBySalesPersonなどがあります。これもアプリケーションに依存しません。部門、住所などの一部のフィールドのルックアップテーブルが多数ある場合があるため、すべてのテキストフィールドを含むテーブルのビューを返すプロシージャがある場合があります。つまり、SalesPersonID、SaleDate、CustomerID、DepartmentID、CustomerAddressIDの代わりに、プロシージャはビューSalesPersonName、SaleDate、CustomerName、DepartmentName、CustomerAddressを返します。これは、アプリケーション間でも使用できます。顧客関係システムでは、請求システムと同様に、顧客名/住所/その他の属性が必要になります。したがって、すべての結合を実行し、1つのクエリですべての顧客情報を取得するものは、おそらくアプリケーション間で使用されます。
したがって、基本的に、テーブルから削除するときは、データの整合性を確保するために、他の3つまたは4つのテーブルから削除する必要がありますか。ロジックがトリガーには複雑すぎますか？次に、すべてのアプリケーションが削除を行うために使用するストアドプロシージャが重要になる場合があります。作成時に行う必要のあることについても同じことが言えます。常に行われる共通の結合がある場合は、すべての結合を行うために1つのストアドプロシージャを用意するのが理にかなっている場合があります。その後、後でテーブルを変更した場合は、手順を同じに保ち、そこでロジックを変更するだけで済みます。
複数のバージョンではなく、1 つの proc を使用するのが理想的です。顧客ごとにバージョンが必要な場合は、すべての顧客に対して 1 db ではなく、顧客ごとに 1 db のアイデアを検討してください。これにより、異なるサーバー上で db をステージングすることもできます (使用量の多いサーバーを大きなサーバーに割り当て、小さなサーバーはハードウェアを共有できます)。
複数のアプリケーション間で Sproc を共有することは意味がないと思います。
関連するアプリケーションでデータベースを共有するケースは見受けられますが、これらのアプリケーションは、データの扱いが互いに大きく異なるため、大部分が別個のものであると考えられます。
同じアーキテクチャを使用するとアプリケーション間で機能する可能性がありますが、複数のアプリケーションで同じビジネス ロジック レイヤーを使用しようとすることを想像してみてください。"ちょっと待って！" 「ばかげている...同じ BLL を使用している場合、なぜ別のアプリを用意する必要があるのですか?それらは同じことを行います!」
QED。
SQL コードを共有する機能を探している場合は、抽象関数のライブラリを構築してみてください。このようにして、一般的なことを行うコードを再利用し、アプリケーションごとにビジネス ロジックを分離することができます。同じことをビューでも行うことができます。ビューは非常に一般的であり、多くのアプリケーションにとって有用です。
作業を進めていくうちに、一般的なストアド プロシージャの用途がそれほど多くないことに気付くでしょう。
とはいえ、非常に設計の悪いレガシー データベースで動作するプロジェクトを実装したことがあります。情報検索を容易にする一連のストアド プロシージャを実装しました。他のチームの他の人が同じ情報を使用したい場合は、ストアド プロシージャをリファクタリングしてより一般的なものにし、コメントとドキュメントのレイヤーを追加し、他の人がプロシージャを使用できるようにしました。その解決策はかなりうまくいきました。
複数のアプリケーション間でデータ スキーマを共有するという概念は難しいものです。非正規化、作成するインデックスなど、常にパフォーマンス上の理由でスキーマが損なわれます。行のサイズを半分に減らすことができれば、1 ページあたりの行数を 2 倍にすることができ、テーブルのスキャンにかかる時間をおそらく半分にすることができます。ただし、メイン テーブルに「一般的な」機能のみを含め、異なる (しかし関連する) テーブルの特定のアプリケーションにのみ関心のあるデータを保持する場合、「単一のテーブル」の考え方に戻るには、どこでも結合する必要があります。
さまざまなアプリケーションをサポートするためのインデックスが増えると、各テーブルのデータを挿入、更新、および削除する時間がますます長くなります。
データベースは負荷分散できないため、データベース サーバーもボトルネックになることがよくあります。データを複数のサーバーに分割できますが、これも非常に複雑になります。
最後に、必要とされる調整の程度は通常非常に大きく、どの要件が優先されるかをめぐってさまざまな部門間で争いが生じ、新しい開発が滞ってしまうことは間違いありません。
一般に、「アプリケーションごとに分離されたデータ サイロ」モデルの方がうまく機能します。私たちが行うことのほとんどすべて (私は契約ソフトウェア ハウスで働いています) は、アプリケーション独自のデータベースを使用して、他のシステムとの間でデータをインポートおよびエクスポートすることに基づいています。
データウェアハウス/意思決定支援システムでは、より簡単かもしれません。私は通常、トランザクションのパフォーマンスが最優先される OLTP システムに取り組んでいます。