多くのアプリケーションでアクセスされるデータベースでストアドプロシージャを使用する人々のアプローチが不思議です。具体的には、アプリケーションごとに異なるストアドプロシージャセットを保持する傾向がありますか、共有セットを使用しようとしているのですか、またはミックスを実行していますか？アプリケーション間でのSQLストアドプロシージャの再利用
一方で、モデルを変更した場合や類似したメンテナンスが少ない場合、SPを再利用することで、変更を少なくすることができます。一方、アプリケーションのニーズがばらついた場合、あるアプリケーションのストアドプロシージャを変更すると、他のアプリケーションが中断される可能性があります。私たちの環境では、各アプリケーションに独自の開発チームがあり、それらの間のコミュニケーションが悪いことに注意してください。データチームはより良いコミュニケーションを持っていますが、主にストアドプロシージャの書き方を担当しています。
ありがとうございます！
すべては抽象化戦略によって異なります。ストアドプロシージャは、抽象化の離散点として扱われるか、またはそれらを呼び出すアプリケーションの別の部分として扱われますか。
これに対する答えは、それらの管理方法を示します。それらが離散抽象である場合、それらを共有することができます。新しい機能が必要な場合は、新しい手順を追加します。彼らがそれらを呼び出すアプリケーションの一部である場合、それらは共有されるべきではありません。
ストアドプロシージャは、要求するアプリケーションではなく、返すデータに基づいて作成する必要があります。 GetAllItemsというストアドプロシージャがある場合は、データベース内のすべての項目を返す必要があります。いずれかのアプリケーションがカテゴリ別にすべてのアイテムを取得したい場合は、GetAllItemsByCategoryを作成します。ストアード・プロシージャーのビジネス・ルールが、データを要求するアプリケーションに基づいて変更される理由はありません。
あなたの質問の最後の部分は、私自身が答えると信じています。
すでに通信が不十分なため、開発チーム間の共有手順は、潜在的な障害箇所を追加するだけで、どちらのチームにも苦労する可能性があります。
私が複数のプロジェクトで作業している場合は、時間を節約して手順を共有しますが、通常、私は少し重複していることがわかりました。後でアプリケーションが発散し始めるとき。
LordScarletも重要な要素を指摘していますが、ビジネスロジックを共有しない一般的なものであれば、問題ではありません。
私の経験では、複数のアプリケーションでSPを共有することが苦痛の原因です。実際、複数のアプリケーションによって直接アクセスされるデータベースを持つことは、最良の長期的なアーキテクチャではないと主張します。
私が推奨し実装したパターンは、1つのアプリケーションだけが各データベースを「所有」し、他のアプリケーションがデータにアクセスして変更するためのAPI（サービスなど）を提供することです。
これは、いくつかの利点があります。
複数のアプリケーションに共通のプロシージャを格納するたびに、それらのプロシージャ（およびビューとテーブルなど）用のデータベースを作成します。そのデータベース（ "base"という名前）には、開発者（またはチーム）が責任を負います（保守とテスト）。
異なるチームが新しい機能を必要とした場合、それを書き込むことができ、ベースの開発者はベースのDBに実装するか、より簡単な方法を提案します。
私は複数のアプリケーション間でSprocsを共有することは理にかなっているとは思いません。
関連アプリケーションでデータベースを共有するケースを見ることができますが、おそらくそれらのアプリケーションはデータを非常に異なる方法で扱うため、大部分は別々のアプリケーションであると考えられます。
同じアーキテクチャーを使用すると、複数のアプリケーションで同じビジネスロジックレイヤーを使用しようとすると想像できます。 "ちょっと待って！" 「それは馬鹿だ...私が同じBLLを使っているのなら、なぜ別のアプリを持っているのだろうか？彼らは同じことをする！
QED。
このように考えてみましょう。ストアドプロシージャは、その下にあるデータについてのものであり、その上にあるアプリケーションについて実際には知ってはいけません。あるアプリケーションが他のアプリケーションが読んでいない方法でデータを読み込んだり更新したりする必要がある可能性があるため、他のアプリケーションが使用しないSPを使用する可能性があります。
私のアプリケーション/データベース/ etcであり、SPを変更してアプリケーションを改善した場合は、より深い設計上の問題があると考えられます。
複数のバージョンではなく1つのprocを理想的に使用します。顧客あたりのバージョンが必要な場合は、すべての顧客に対して1 dbとは対照的に、顧客あたり1 dbの考え方を調査します。これはまた、異なるサーバ上でのデータベースのいくつかの面白いステージングを可能にします（より大きい/より重い使用法をより大きなサーバに割り当てる一方、より小さいものはハードウェアを共有することができます）
SQLコードを共有する機能を探すなら、機能。こうすることで、一般的なことを行うコードを再利用し、アプリケーションごとにビジネスロジックを分離することができます。これらのビューは、多くのアプリケーションで非常に汎用的で有用なものにすることができます。
あなたが行っている共通のストアドプロシージャには、それほど多くの用途がないことがわかります。
私たちはかつて非常にひどく設計されたレガシーデータベースで作業していたプロジェクトを実装したと言いました。私たちは情報検索を容易にする一連のストアドプロシージャを実装しました。他のチームの他のユーザーが同じ情報を使用したかったときに、ストアドプロシージャをリファクタリングして汎用性を高め、追加のコメントとドキュメントを追加し、他のユーザーが手続きを使用できるようにしました。その解決策はかなりうまくいった。
ストアドプロシージャは、それを使用するアプリケーションによって変更されないビジネスルールを公開する必要があります。これにより、使用されている場所の代わりに一度ルールを保存して更新することができます。これは悪夢です。
私たちは可能な限り単一の共有ストアドプロシージャを使用しようとしていますが、あなたも同様に説明しています。私たちは、格納されたprocs（ApplicationName_StoredProcName）にアプリケーションプレフィックスを追加することによってそれを処理しました。
これらのストアドプロシージャは、集中管理された「マスター」ストアドプロシージャを呼び出すことがよくありますが、この方法では、アプリケーション固有の変更が発生する可能性があります。
多くのストアドプロシージャはアプリケーションに依存しませんが、アプリケーションによってはいくつかの方法があります。たとえば、CRUD（Create、Select、Update、Delete）ストアドプロシージャはアプリケーション間で移動できます。特に、監査ロジックを投げ込むことができます（トリガーで実行されることもありますが、トリガーに入ることのできる複雑さには限界があります）。ソフトウェア・ショップに標準アーキテクチャーのタイプがある場合、中間層は、プロシージャーが共用されるアプリケーションに関係なく、ストアード・プロシージャーを使用してデータベースを作成/選択/更新/削除する必要があります。
同時に、データを見るにはいくつかの有用な方法があります。つまり、GetProductsSoldBySalesPersonなどです。これはアプリケーションにも依存しません。部門や住所などのフィールドにはルックアップテーブルがたくさんあるので、すべてのテキストフィールドを含むテーブルのビューを返す手続きがあるかもしれません。つまり、SalesPersonID、SaleDate、CustomerID、DepartmentID、CustomerAddressIDの代わりに、プロシージャはSalesPersonName、SaleDate、CustomerName、DepartmentName、CustomerAddressのビューを返します。これはアプリケーション間でも使用できます。顧客関係システムは、請求システムと同様に顧客名/住所/その他の属性を必要とする。したがって、すべての結合を行い、すべての顧客情報を1つのクエリで取得したものは、おそらくアプリケーション全体で使用されます。間違いなくデータを表示する方法を作成することは、ビューのドメインですが、多くの場合、これを行うストアドプロシージャを使用していました。
基本的に、テーブルから削除する場合は、3つまたは4つの他のテーブルから削除してデータの整合性を確保する必要があります。トリガーにはロジックが複雑すぎますか？その後、すべてのアプリケーションが削除を行うために使用するストアドプロシージャが重要になります。同じことが創造のときに必要なことにも当てはまります。共通の結合が常に行われている場合は、すべての結合を行うストアド・プロシージャを1つ持つことが理にかなっています。その後、後でテーブルを変更する場合は、手順を同じに保ち、そこでロジックを変更することができます。
複数のアプリケーション間でデータスキーマを共有するというコンセプトは厳しいものです。通常、パフォーマンス上の理由からスキーマが危険にさらされます。行のサイズを半分に減らすことができれば、1ページあたりの行数を2倍にすることができ、おそらくテーブルをスキャンするのにかかる時間を半分にすることができます。ただし、メインテーブルに「共通」機能のみを含め、異なる（ただし関連する）テーブル上の特定のアプリケーションに関心のあるデータのみを保持する場合は、どこにでも参加して「単一テーブル」のアイデアに戻る必要があります。
異なるアプリケーションをサポートするインデックスが増えると、各テーブルのデータを挿入、更新、削除する時間がますます増えます。
データベースの負荷分散ができないため、データベースサーバーにもボトルネックになることがよくあります。データを複数のサーバーに分割することはできますが、それも非常に複雑になります。
最後に、必要とされる調整の程度は、通常、巨大であり、その要件を優先する異なる部門間の戦いに間違いなく、新しい開発が渋滞することになります。
一般に、「アプリケーションごとに独立したデータサイロ」モデルが効果的です。私がやっていることは、契約ソフトウエアハウスの仕事のほとんどは、アプリケーションのデータベースを使って他のシステムとの間でデータをインポートしたり、他のシステムにデータをエクスポートしたりすることに基づいています。
データウェアハウス/意思決定支援システムのほうが簡単かもしれません。私は通常、トランザクションのパフォーマンスが最も重要なOLTPシステムに取り組んでいます。
+1これは実際にはうまく機能します – Andomar