44

ストアドプロシージャのビジネスロジックに対する賛否両論は何ですか？

4

17 に答える 17

37

ストアドプロシージャに対して：プログラミングスペースのビジネスロジック

私は表現力を重視していますが、SQLスペースがそれほど表現力に富んでいるとは思いません。最も適切なタスクのために手元にある最高のツールを使用してください。ロジックや高次の概念をいじるのは、最高レベルで行うのが最適です。したがって、ストレージと大量のデータの操作は、サーバーレベルで、おそらくストアドプロシージャで行うのが最適です。

しかし、それは状況によって異なります。複数のアプリケーションが1つのストレージメカニズムと相互作用していて、その整合性とワークフローを確実に維持したい場合は、すべてのロジックをデータベースサーバーにオフロードする必要があります。または、複数のアプリケーションでの並行開発を管理する準備をします。

于 2009-01-27T18:16:43.400 に答える
26

私はそれに対して徹底的に反対しています。最大の理由の1つは、earinoが述べた最初の理由です-それは1つの場所に住んでいます。ソース管理に簡単に統合することはできません。2人の開発者がストアドプロシージャで同時に作業することはほぼ不可能です。

私の他の主な不満は、SQLが複雑なロジックを表現するのがあまり得意ではないということです。スコープの概念はありません。コードを再利用する機能が少ないため（オブジェクト指向言語とは対照的に）、コードはコピーペーストされる傾向があります。

そこで開発するには、開発者にデータベースへのアクセスを許可する必要があります。私がデータで働いてきた多くの組織では、人々は開発者とは異なる世界にいて、異なる権限を持っているなどです。このような場合、開発者をデータベースから除外するのは難しいでしょう。

于 2009-01-27T18:17:37.050 に答える
19

私は、ビジネスロジックが次のようになっている限り、次のように述べている学派です。

  • 一箇所に住んでいます
  • 適切に文書化されている場所
  • 緩く結合できるサービスを通じて適切なアクセスが提供されます
  • 公開された抽象化されたインターフェースを介して

ロジックがストアドプロシージャ、J2EE中間層、クリップエキスパートシステム、またはその他の場所にあるかどうかは関係ありません。私たちのビジネスロジックをどこに保存しても、「悲惨さの保存の法則」は、コンポーネント/リポジトリXをテクノロジー/メソッドYに交換する必要があるため、誰かがそれが間違った考えであると言うことを保証します。

于 2009-01-27T18:07:56.663 に答える
14

いくつかの考え: これは Java 中心の応答であることに注意してください。ただし、これは私の最近 (過去 10 年間) の経験の大部分です。

(1) (大規模な) 開発者チームによる並行開発。アプリケーションが非常に複雑で、各開発者が独自のプライベート バージョンの DB (有人リンク/参照データなどを使用) をセットアップできない場合、すべての開発者のチーム全体で作業することは非常に困難です。 PL-SQL (たとえば) パッケージの同じセットを同時に共有 DEVL DB に格納しますか? 次に、無効な手順/テーブルへのコードの不一致を使用してDBで作業することに固執しました（私の経験）...

Java アーキテクトとして、各開発者が自分のデスクトップにプライベートな JBoss インスタンスを持ち、独自の機能セットで簡単に作業し、他の人に影響を与えることなく自分のペースで統合する方がはるかに簡単だと思います.... ..

(2) 継続的インテグレーション ツールセット DB の世界には同様の「概念」がいくつか存在しますが、私の経験から、次の組み合わせが示されています (ここでは、現在の最高の組み合わせのお気に入りを選んでいます)。

  • mvn - ビルドシステム
  • junit - 自動化された単体テスト
  • nexus - レポ マネージャー (アーティファクトのライフサイクル バージョン、スナップショット、およびリリースを管理します)
  • hudson - ci ビルド サーバー
  • sonar - 静的分析ツール / コード カバレッジ レポート / ALOT もっと見る

上記のすべて (無料のツール) を使用して大規模なプロジェクトを実行すると、一貫性のある簡単な方法で XP を大衆に提供し、IT スタッフ全体に品質管理を実施できます。Oracle / PL-SQL には一致するツールセットがありません

(3) ツール / ライブラリ / など... Java は、他のプラットフォームがアクセスできない驚くべき一連のサービス (無料のものもあれば、そうでないものもあります) にアクセスできます。log4j のような基本的なものでさえ (PL/SQL にはありますが、ほとんど同じではありません)、開発者がその場で変更できる柔軟に調整可能なロギングを作成できるようにするなどのことが可能です (ダブギングに最適です)。 . 自動化された API ドキュメント (javadoc 経由)。自動化された単体テスト カバレッジ レポート。デバッガーが統合された信じられないほどの IDE (Eclipse) / アプリ サーバーへの自動デプロイ。太陽の下であらゆるタイプのサービスと連携する API、何でもできるオープンソース ライブラリ、すべてのベンダーによる 100% サポート

(4) サービスの再利用。誰かがコメントしたことは真実です。負荷の高いデータ駆動型のビジネス ルール がある場合、これらは DB レイヤーに存在する必要があると主張できます。なんで？中間層がすべてそのロジックを複製する必要がないようにします。

しかし、データ駆動型ではないビジネス ルールや、OO がより自然な選択となるほど複雑なビジネス ルールについても同じことが言えます。すべてのビジネス ロジックを DB に貼り付けると、DB 経由でのみ利用可能になります。

  • クライアントまたは中間アプリ層で検証を行い、DB への往復を節約したい場合はどうすればよいでしょうか?
  • 読み取り専用データを (パフォーマンスのために) 中間層にキャッシュし、キャッシュされたデータに対してビジネス ルールを実行する場合はどうすればよいでしょうか?
  • DB アクセスを必要としない中間層サービスがある場合、または独自のデータを提供できるクライアントがある場合はどうでしょうか?
  • ビジネス ルールのデータ依存部分が外部サービスにアクセスする必要がある場合はどうすればよいでしょうか。次に、次のような断片化されたビジネス ロジックで終了します。

私

retCode = validateSomeDate(date);
if (retCode == 1) then
   evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
   sendEmailMsg(....)
else if (retCode == 2) then
   performOtherBizLogicStuf(...) //again, may need data, may not need data
   triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL 
fi

上記のように記述されたシステムを午前 2 時にデバッグする必要があったことは、誰もが知っていると思います。ビジネス ロジックが階層間で断片化されている場合、複雑なプロセスの一貫した感覚を得ることは非常に難しく、場合によっては維持することが不可能になります。

于 2010-05-23T23:47:50.280 に答える
11

「それをソース管理に簡単に統合することはできません。」-ストアドプロシージャを作成するコードをバージョン管理されたスクリプトに入れると、その異論はなくなります。Scott Amblerのアジャイルデータベースのアイデアに従う場合、それはまさにあなたがすべきことです。

すべての開発者が優れたデータモデラーであるとは限りません。SQLについてのちょっとした知識が彼らをデータベースの専門家にしたと思った開発者によって作成された恐ろしいスキーマを考えることができます。開発者がDBAやデータモデラーと協力することには多くの価値があると思います。

データベースを使用するアプリケーションが1つだけの場合、ビジネスロジックは中間層に表示される可能性があります。多くのアプリがデータベースを共有している場合は、データベースに配置することをお勧めします。

SOAは中道を提供します：サービスはデータを所有します。サービスのみがデータにアクセスできます。データを取得するということは、サービスを利用することを意味します。その場合、どちらの場所にもルールを置くことができます。

アプリケーションは行き来しますが、データは残ります。

于 2009-01-27T18:26:21.323 に答える
9

ビジネスロジックをsprocsに格納しないもう1つの理由-DBのスケーリング機能が制限されています。データベースがボトルネックになるのは非常に一般的な状況です。そのため、DBの負荷をできるだけ多く取ることをお勧めします。

于 2009-01-27T18:32:59.157 に答える
6

ビジネスロジックは1か所にカプセル化する必要があります。ロジックが常に実行され、一貫して実行されることを保証できます。データベース上のエンティティに関連するすべてのアクティビティを実行する必要があるクラスを使用すると、すべての検証が正しく実行されることが保証されます。このコードには1つの場所があり、プロジェクトの開発者は誰でもこのクラスを簡単に開いてロジックを確認できます（ドキュメントは古くなる可能性があり、古くなる可能性があるため、コードは唯一の信頼できるドキュメント形式です）。

これは、ストアドプロシージャでは困難です。同じテーブルを処理する複数のsprocがある場合があります。複数のsprocをチェーンして、ロジックが1つだけに存在するようにすると、扱いにくくなります。それがストライキ1です。データベース内の「エンティティXを取り巻くすべてのビジネスルールは何ですか」をどのように判断しますか？それを追跡しようとしている何千ものsprocを検索して楽しんでください。

2つ目は、ビジネスロジックを永続性メカニズムに結び付けていることです。すべてのデータを同じデータベースに保存したり、一部をXMLなどに保存したりすることはできません。このタイプの不整合は開発者にとって困難です。

ロジックがデータベースにのみ存在する場合、検証を実行するのは困難です。データ入力フォームのすべてのフィールドを検証するために、本当にsprocを呼び出しますか？検証ルールとビジネスロジックは親密な関係にあります。このロジックはすべて同じ場所で実行する必要があります。

于 2009-01-27T18:24:09.440 に答える
5

+：SQLサーバーがコードを最適化することがある

+：パラメータを渡す必要があります。これによりSQLインジェクションの問題が制限されます

-：コードは単一のデータベースに依存しています（一部のデータベースにはSPさえありません）

-：コードを変更するには、データベースに接続する必要があります

-：ロジックがうまく整理されていません

個人的には反対ですが、忙しいウェブサイトで一度は使わなければなりませんでした。MS SQLでSPを使用すると、大きなメリットがもたらされましたが、キャッシュを実装すると、それらのメリットはそれほど大きくなくなりました。

于 2009-01-27T18:16:04.853 に答える
4

ビジネスロジック層にある場合は、ビジネスロジックを単体テストできます。完全に分離している場合は、永続化操作をモックできるため、BLのみをテストします。ストアドプロシージャは、linqやc＃などよりも、保守/デバッグ/単体テストがはるかに困難です。

于 2011-10-05T09:49:12.947 に答える
4

という言葉があります...

ハンマーしかないときは、すべてが釘のように見えます。

私の謙虚な意見では、すべての状況に適合する唯一の答えはありません。多くの人が、ビジネス ロジックをデータベースに入れることは常に間違っていると思い込んでいるように思えます。

トランザクション処理、特にバルク操作をデータベース側で非常に効率的にするために、多くの作業が行われました。また、データベースに対する意見のほとんどが形成されて以来、データベースのコード管理は大幅に改善されました。

データベース サーバーを単なる永続化レイヤーと見なすのは間違っていると思います。処理アクティビティが DB サーバーで実行されたときに最も効率的である場合は、そこで実行してください。

そうでない場合は、他の場所でそれらを行います。

それはすべて、現在取り組んでいるアプリケーション、一緒に働いているチーム、そしてあなたを雇った顧客に最適なものは何かということになります。

それはちょうど私の2セントです。

于 2010-12-03T21:46:11.223 に答える
0

@Nick「私は完全に反対です。最大の理由の 1 つは、earino が述べた最初の理由です。それは 1 つの場所に存在します。ソース管理に簡単に統合することはできません。ストアド プロシージャを同時に実行します。」

ストアド プロシージャにビジネス ロジックを配置することを主張しているわけではありません (まったく逆です)。しかし、あなたが提唱したこれらの理由は意味がありません。ストアド プロシージャは、ソース管理に格納できる単純な sql/DDL 成果物であり、展開成果物でもあります (つまり、展開のためにデータベース管理者に引き渡されるものであり、war/ear を引き渡すのとほぼ同じ方法です)。アーティファクトを IT/展開の連絡係に) 1 人または複数の開発者が、ブランチ、バージョン管理、およびマージによって、単純な古いソース コードで行うのと同じ方法で、ソース管理から離れた同じストアド プロシージャで作業できます。

ここで、ストアド プロシージャ (およびそれらを含むパッケージ) の唯一のコピーがデータベースにのみ存在する場合、明らかにソース管理 (およびそれに関連するすべての問題) でそれを制御することはできません。しかし、それはストアド プロシージャの問題ではなく、そのコードの使用方法に関する不適切な問題です。これは、ソース コードのコピーが 1 つしかないのと同じように、無能さの表れです。

私は Java と PLSQL/DDL の両方の大量のコードを含むシステムで作業してきましたが、それらはすべて clearcase でバージョン管理されていました。それらはすべて、さまざまなチームが作業する厳密なプロセスでコンパイルおよび展開されるソース コードとして扱われました。あなたが説明しているように問題はありませんでした。

ストアド プロシージャにビジネス ロジックを配置しないコンテキスト固有の理由がありますが、これらは有効な理由ではありません。

于 2009-12-08T04:14:34.963 に答える