1


0

私の現在のプロジェクトでは、ビジネスロジックはストアドプロシージャ(そのうち1000個)に実装されていますが、ビジネスの成長に合わせてスケールアップしたいのです。 アーキテクトは、パフォーマンスとスケーラビリティを向上させるために、ビジネスロジックをアプリケーション層(.net)に移動することを決定しました。 しかし、彼らは何かを再設計/書き換えていません。 一言で言えば、SPから起動されるのと同じSQLクエリは、ADO.Netを使用して.net関数から起動されます。 これによりどのようにパフォーマンスが得られますか?

私の理解の限りでは、DBの独立性が必要な場合、またはRDBMSエンジンよりもOOP言語でよりよく実装できるビジネスロジックがある場合は、ビジネスロジックをアプリケーション層に移動する必要があります。等..)。 他のケースでは、実装する複雑なビジネスロジックがない場合は、ビジネスロジックをDB自体に保持するほうが良いと思います。少なくともアプリケーション層とDB間のネットワーク遅延はこのようにして回避できます。

あなたの意見を教えてください。 私は少しちゅうちょしながらいくつかのアーキテクチャの決定を見ている開発者です、この件についての私の無知を許してください。

4 Answer


1


このようなアーキテクチャ上の議論では、パフォーマンスを単独で検討する場合や、応答時間などパフォーマンスの1つの側面のみを検討する場合など、多くのトレードオフを検討する必要があります。

データベース層でロジックを実行することと、データをアプリケーション層に送り返すこと、そしてそこで処理することとの間には明らかにある程度のトレードオフがあります。 データ出荷コストと処理コスト ビジネスロジックのコストと複雑さが重要な要素になることを示したように、出荷されるデータのサイズは別のものになります。

DB層が使用中になっている場合は、個々の応答時間が増えても、別の層へのオフロード処理によって全体的なスループットが向上する可能性があります。 追加の負荷に対処するために、アプリケーション層を拡張することができます。 ここで、パフォーマンスが改善された(全体的なスループットが向上した)、または悪化した(応答時間が大幅に増加した)と言いますか。

ここで、アプリケーション層が興味深いキャッシング戦略を実装する可能性があるかどうかを検討します。 たぶん私たちは非常に大きなパフォーマンスの勝利を得ています - いくつかの要求に対してDBに全く負荷をかけません!


1


ビジネスロジックがまだSQL文の中にある場合、データベースは以前と同じくらい多くの作業を実行することになり、パフォーマンスが向上することはありません。 (ストアドプロシージャが使用されたときほど効率的にクエリプランをキャッシュできない場合は、より多くの作業が必要になる可能性があります)

パフォーマンスを向上させるためには、いくつかの作業をアプリケーション層に移動する必要があります。たとえば、アプリケーションサーバーにデータをキャッシュし、データベースにアクセスせずにルックアップまたは検証チェックを実行できますか。


1


私はそれらの決定が建築の教義を使って正当化されるべきではないと思います。 データはもっと意味があります。

「すべてのビジネスロジックはストアドプロシージャに属している」または「すべてが中間層にあるべきだ」などの文は、それぞれデータベースまたはオブジェクトに知識が限定されている人々によって作成される傾向があります。 あなたが判断するとき、そして測定値に基づいてそれをするとき、両方を組み合わせるほうがよい。

たとえば、プロシージャの1つが大量のデータを処理してほんの一握りの結果を返す場合、それをデータベースに残すべきであるという議論があります。 何百万もの行を中間層のメモリーに入れ、それらを整理してから、別のラウンドトリップでデータベースを更新することには意味がありません。

別の考慮事項は、データベースがアプリ間で共有されているかどうかです。 そうであれば、ロジックはデータベース内に留まるべきであり、そうすれば誰もがそれを使用することができる。

中間層は行き来する傾向がありますが、データは永遠に残ります。

私は自分自身がオブジェクトの男ですが、軽く踏みます。

それは複雑な問題です。 白黒の陳述があらゆる場合にうまくいくとは思わない。


1


他の人がすでに言ったように、それは多くの要因に依存します。 しかし、あなたからの質問から、アーキテクトはストアドプロシージャをDB内からアプリケーション内の動的SQLに移行することを提案しているようです。 それは私にとって非常に疑わしいようです。 SQLは集合指向の言語であり、大量のデータレコードのマッサージを必要とするビジネスロジックはSQLの方が優れているでしょう。 複雑な検索とレポートタイプの機能を考える。 一方、対応するビジネスルールの検証による広告申込情報の編集は、プログラミング言語で行うほうがはるかに優れています。 アプリ層でゆっくりと変化するデータをキャッシュすることも、もう1つの利点です。 すべてのデータへのゲートウェイとして機能する専用の中間層サービスがある場合、これはさらに優れています。 データが異種のアプリケーション間で直接共有されている場合は、procを格納することをお勧めします。 また、組織内のSQLの才能とプログラミングの才能の可用性/経験を考慮する必要があります。 この質問に対する一般的な答えはありません。