Oracleデータベースのストアドプロシージャにビジネスロジックを実装するアプリケーションを開発しています。それは数年前からこのようになっています。ビジネスルールは多種多様で、特定の顧客向けにカスタマイズされることがよくあります。
現在、それらはデータ管理およびデータ取得コードと多少混ざっています。 私はBRMSのロジックの一部を移動することを提案することを考えていました。
私の同僚は、次の理由でそれに反対する可能性があります。
彼らは、PLSQLに基づく現在の実装は、中間層、つまりJavaにロジックが実装されている実装よりもかなり効率的であることを経験しました。
多くの場合、ユーザーはソフトウェアからの応答時間を短くする必要があります。これは、ソフトウェアが産業環境での操作も指示するためです。
私たちのチームは大きくはなく、ビジネスルールに最も精通している人々は、ストアドプロシージャを実装した人々でもあります。これらはJavaでの作業には使用されません。とりわけ、PLSQLを使用すると、フレームワーク、システム統合、および異なる層間のマッピングに関するすべての問題を無視できます。
PLSQL以外のものに切り替える場合は、多くのJavaコーディングを必要とせず、フレームワークに依存しないものである必要があります。
PLSQLを使用すると、アプリケーションの重みを高価なDBMSに活用できます。理想的には、BRMSとDBMSを効果的に統合したいと考えています。
私の提案をよりよく提示するには、次の問題についていくつかの客観的な数字が必要です。
- 保存された手順からBRMSに移行した場合のパフォーマンスの低下
- DBMSとBRMSの統合
- PSLSQLおよび純粋なJavaコードによって提供されるものと比較したBRMSによって提供される抽象化
- スイッチに必要なトレーニング
私はネットを調べて、いくつかの参照を見つけました。残念ながら、それらのほとんどは、純粋なJavaコードとストアドプロシージャ、または純粋なJavaコードとBRMSのいずれかの実装を比較しています。ストアドプロシージャとBRMSを比較したり、ストアドプロシージャソリューションをBRMSと統合する方法を説明したりするものは見つかりませんでした。
どうもありがとう。