Webアプリケーションのストアドプロシージャにすべてのビジネスロジックを保持することの長所と短所
ある組織では、Webアプリケーションで働いていたすべてのビジネスロジックをデータベースストアドプロシージャに基づいて開発しています。たとえば、ビューとしてhtmlを使用し、コントローラーとしてサーブレットを使用して、クライアント要求を適切なデータベースストアドプロシージャに転送します。
この種の設計の長所と短所は何ですか？私の意見では、ビジネスロジックがデータベースに大きく依存している場合は、この種の設計に従うほうがいいです!!!!!!
理論的には、長所と短所は次のとおりです。
長所：
- すべてのビジネスロジックを1か所に
- 複数のSQLクエリなどを1回のデータベースへの「ラウンドトリップ」で実行できるため、おそらくより高速なアプリケーション
- 複数のアプリケーションからのストアドプロシージャを利用するのは簡単です
短所：
- パフォーマンスのチューニングにはDBAが必要です
- すべての開発者は、特定のSQL方言（T-SQL、Pl/SQLなど）に精通している必要があります。
- SQLコードは表現力に欠けるため、実際にはデータに関連しないより高いレベルの概念をカバーする場合、作成が難しくなります。
- データベースへの不要な負荷が大幅に増える
現在、実際には、愚か者だけがデータベースにすべてのビジネスロジックを持っています。
- アプリケーション全体で簡単に機能する一貫したストアドプロシージャインターフェイスを作成できる開発者はほとんどいません。通常、これは、呼び出し側のアプリケーションに特定の前提が設けられているためです。
- これらすべてのストアドプロシージャを文書化する場合も同様です
- データベースサーバーは通常、そのままの形で十分にボトルネックになっています。それらに不必要な負荷をかけると、このボトルネックがさらに狭まります。トラフィックがまともなものには、複雑なロードバランシングと強力なハードウェアが必要です。
- SQLはほとんどプログラミング言語ではありません。 T-SQLストアドプロシージャとして記述されたスクリプトエンジンを維持できることはかつてありました。遅く、理解するのはほぼ不可能であり、ほとんどの言語で取るに足らない拡張機能を実装するのに何日もかかった
- 別のSQLサーバーを実行するためにデータベースを必要とするクライアントがある場合はどうなりますか？基本的にゼロから始める必要があります-データベースに非常に結びついています。ストアドプロシージャ全体で数百回使用するいくつかの機能をMicrosoftが廃止することを決定した場合も同様です。
- ソース管理をストアドプロシージャで適切に実行することは非常に困難です。
- データベースの同期を保つのは困難です。データベースで同時に作業している2人の開発者の間で何らかの競合があった場合はどうでしょうか？ 「開発データベース」の設定によっては、実際には気づかない他のコードを上書きしてしまいます
- 使用するデータベースエンジンに関係なく、ツールの操作は明らかに簡単ではありません。
だから、客観的に質問に答える。ほとんどの場合、ストアドプロシージャは一部の場合にのみ必要です。たとえば、いくつかの大きなテーブルで多くの条件付き処理を実行する必要がある場所を生成するレポートがある場合、アプリケーションがデータベースに対して数百のSQLクエリを実行することは望ましくありません。ストアドプロシージャを作成して、ネットワークラグのオーバーヘッドが発生しないようにする必要があります。また、通常は、クライアントがデータベース全体でカスタムっぽいクエリを実行したい場合にのみ、ストアドプロシージャを作成します。ストアドプロシージャとビューを使用すると、クライアントがデータベースに精通していなくても、これを簡単に実現できます。
短所：
- データベースは、アーキテクチャの最も少ないスケーラブルな部分です。
- 特にWebサービスとRESTフルサードパーティWebアプリケーションの時代には、すべてのビジネスロジックをストアドプロシージャに含めることができません。
- SQLの実装はさまざまで、一部は注意が必要な場合があり、ファーストクラスのアプリケーション層プログラミング言語ほど流動的に読み取れるものはありません。
- コードはreadよりも頻繁にwriteされることを覚えておいてください。
Webアプリケーションのストアドプロシージャに関するすべてのビジネスロジックを保持する長所：
- 1つの場所は複数の場所よりも維持が簡単です
- データベースは高速で最適化されており、適切にスケーリングできます。
- 同じ手順を複数の異なるフレームワークや言語から呼び出すことができます。
- ロジックは、特定のアプリケーションの実装から切り離されています。
- データベースが変わらない場合、アプリケーションの変更による手直しを減らすことができます。
Webアプリケーションのストアドプロシージャのすべてのビジネスロジックを保持する短所：反対：
- 多くの場所では、SQLに関する優れた知識を見つけるのが難しい場合があります。
- 優れたSQLコーダーは高価になる可能性があります。
- すべてのアプリケーション開発者は、それを変更するか、迅速な変更を要求できる必要があります。
- SQLデータベースにあまり適さない一部のデータ（例：画像データまたはドキュメントデータがデータベースで使用できない場合があり、ストアドプロシージャと統合するのが難しい場合があります。
私が通常遭遇する2つの大きな短所があります。
- ストアドプロシージャを単体テストできない。もちろん、単体テストフレームワークはいくつかありますが、通常、一度に複数のテストセットを実行するという問題に直面します（同時実行性とトランザクションの問題）。
- ほとんどの企業は、多くのログインをストアドプロシージャに配置することを望んでいますが、データベースプログラマやDBAの5倍のアプリケーションプログラマ（C＃、Ruby、Javaなど）を採用し、何らかの理由ですべてのアプリプログラマが（PL/SQL、T-SQLなどの）高性能でスケーラブルなデータベースプロシージャを完全に理解し、記述できること。経営陣は通常、これをC＃の専門家に依頼してPythonコードを記述し、なぜ彼らが素晴らしいアプリケーションを作成していないのか疑問に思っていること）によく似ていることに気づきません。
場合によります
それはすべてあなたのteam's experience そしてあなたの project's requirements。 DBAをチームに招き、要件を満たすために何をすべきかを決定します。ただし、多層アプリケーション設計では、ビジネスロジックをストアドプロシージャにカプセル化することは適切な決定ではない場合があります。
それは問題ではありません
ビジネスロジック：
- 一箇所に住んでいる
- 適切に文書化されている場所
- 疎結合できるサービスを通じて適切なアクセスが提供されます
- 公開された抽象化インターフェースを介して
business logic in programming space makes more sense いつ Power of Expressionはチーム/プロジェクトで重要です。
SQLスペースはそれほど表現力がないと思いますが、it can do the job。最も適切なタスクのために手元にある最高のツールを使用します。ロジックと高次の概念をいじるのは、highest level.結果として、おそらくストレージおよび大量のデータ操作はサーバーレベルで行うのが最適です、おそらくストアドプロシージャで行います。
現代では、これはもはや一般的なアプローチではありません。ストアドプロシージャにビジネスロジックを配置することは、Webプログラミングの早い段階で一般的に行われることでした。今日私はそれに反対することをお勧めします。
ストアドプロシージャのビジネスロジックについては、長所と短所を比較検討した結果、どういうわけか他のアプローチを打ち負かした選択肢として正当化できるものはないと私は言わなければなりません。 PROポイントは、せいぜい学術的なものです。
CONのlinqコードではありません。 TSQLの未来はlinqにコンパイルされています。
コンパイルされたコードはより安定しており、扱いやすくなっています。何かをデバッグしている場合、C＃やJavaを使用すると、非常に多くの情報を入手できます。
ストアドプロシージャは多くの責任を負うことになる可能性が高いため、責任を1に維持することを試みることをお勧めします。
責任の分離の欠如は、コアクラスがますます大きくなるため、作業がますます難しくなり、安定性が低下するアプリケーションにつながります。
Microsoft Asp.Net MVCをEntity Framework Code Firstと組み合わせると、アプリケーションを迅速に構築でき、ストアドプロシージャは不要になります。