銀行部門では、ビジネス ロジックにストアド プロシージャを使用します。それらのロジックは、ビジネスロジックレイヤーではなくデータベースに移動されます。
銀行がストアド プロシージャを要求する理由は何ですか?
よろしく
1394 次
2 に答える
3
ストアド プロシージャは、メインフレームに 30 年間存在していた可能性があります。その間、クライアント言語は出入りしました。
とにかく、「ビジネス ロジック」を定義する必要があります。多くの「ビジネス ロジック」は、「データの整合性」ルール (「子行の集計がゼロの場合にのみこのカウントを設定する」など) に帰着します。アトミック。
関連している：
- メインフレームがまだ存在する理由 （それで）
- 移植可能な SQL を作成する必要性や利便性はどの程度ですか? （それで）
- ストアド プロシージャを使用する理由 (ブログ)
簡単に言えば、私のDBコードはあなたのクライアントコードよりも長生きします...
于 2010-07-17T09:24:03.300 に答える
3
これは、私が働いてきた多くの銀行には当てはまりません。銀行のアプリケーションは、他の企業のアプリケーションと同じであり、ほぼ完全にストアド プロシージャでコーディングされているものから、ストアド プロシージャを完全に避けて ORM のようなものを使用するものまでさまざまです。
ストアド プロシージャにロジックを配置することを選択する理由について教えてください。場合によっては、それを行うのが賢明な場所です。ALT.NET の群衆 (または、選択したプラットフォームの NoSQL/ORM ファンボーイ) は、ストアド プロシージャは悪であり、ORM が唯一の合理的な解決策であると信じ込ませることを知っていますが、現実の世界では、実際のアプリケーションを実際のアプリケーションで構築しています。要件が異なるため、それほど単純ではありません。
于 2010-07-17T08:52:26.457 に答える