私の仕事では、ストアドプロシージャを使用してデータベース内にビジネスロジックを保持することを主張する友人がいます...
そのようなことをしないように彼を説得するために私が使用できる議論は何ですか？
彼がこれを実行したい理由は、さまざまなプラットフォームを備えた複数のシステムがあるためです（.NETのWebアプリケーションとVB.NET、およびPower Builderで開発された別のデスクトップアプリケーション-Sybase）。
ありがとう！
質問する
314 次
5 に答える
3
そのようなことをしないように彼を説得するために私が使用できる議論は何ですか?
それに対するあなたの議論は何ですか？ストアド プロシージャを避けたいと思うのはなぜですか。
これは実際には悪い考えではありません。異なる言語で記述された異なるシステムがデータベースにアクセスする場合、少なくともビジネス ロジックの一部をデータベースに保持しておくと役立つ場合があります。
于 2010-02-12T10:44:12.923 に答える
2
いくつかの理由から、私は Web サービスを選びます。
- サービスをあらゆる種類のクライアントに公開して使用できます
- より柔軟で、デバッグやテストに便利です
- ソース管理のサポートが向上します
- あなたのプログラミング言語は、おそらく SQL よりも表現力が高いでしょう。
于 2010-02-12T10:44:20.560 に答える
2
- 強く型付けされていません。
- 簡単にリファクタリングできず、実行時にクライアントが壊れます。
- 単体テスト不可。
- ほとんどの場合、すべてのビジネス ロジックがストアド プロシージャになるわけではないため、ロジックはデータベースとコードに分割されます。
- ストアド プロシージャは、プログラミング言語ほど有能でも強力でもない
- クライアントがデータスキーマの内部を知る必要がある適切なレベルのカプセル化を取得するのが難しい
- バージョン化が難しい
- ビジネス ロジックはデータベース ベンダーに結び付けられており、一生そのベンダーに縛られている
Edit: other user-contributed points:
- スケーリングが難しく、費用がかかる
于 2010-02-12T10:44:46.450 に答える
2
プロの Web サービス、コン データベース ロジック:
- データベースが他のユーザーと共有されている場合、ロジックをデータベースに配置すると、アプリはデータ層と論理層の両方で結合されます。それは通常悪いことです。
- データベースサーバーの負荷が気になります。リレーショナル データベースがクエリや計算によって打撃を受けている場合、中間層が計算を行っている場合ほど簡単にスケールすることはできません。
プロのデータベース ロジック、詐欺の Web サービス:
- データベースがアプリによって完全に所有されている場合、ロジックをデータベースに配置することは、おそらく受け入れられる選択です。
- データベースの切り替えは、中間層の変更よりもめったに起こらないので、私はそれほど心配していません。ミドルウェアの流行は行き来しますが、データはあらゆるビジネスの王冠です。
- Web サービスにも欠点があります。XML をオブジェクトに変換して戻すことは、CPU サイクルの無駄です。インメモリ呼び出しは、ネットワーク呼び出しよりも桁違いに高速です。今日の「単純な」サービスへの 1 回の往復は 200 ミリ秒かもしれませんが、それらを合計し始めると、すぐに SLA がなくなります。
ドグマに屈しないでください。両方の長所と短所を考慮し、アプリの特定の状況に基づいて合理的な決定を下してください。あなたもあなたの同僚も、白黒の感情的な決定を下したように聞こえます. 覚えておいてください：結果はあなたを人として反映するものではありません. それが生産された後、デザイナーとしてのあなたについてそれが何を言っているのかがわかります.
于 2010-02-12T11:11:55.973 に答える
1
とにかく、DB を使用して、最も得意とすることを実行するだけです。集計やデータの整合性など。
しかし、すべてのシステムは妥協です。5 つの異なるクライアント セットがある場合、DB が最適な場所である可能性があります。すべてのスプレッドシートまたは Access DB が、美しい中間層 Web サービスを呼び出せるわけではありません...
于 2010-02-12T10:57:33.817 に答える