3 層アーキテクチャを持つ多くの Web アプリケーションは、アプリケーション サーバーですべての処理を行い、データベースを永続化するためにデータベースを使用して、データベースの独立性を確保しています。莫大な費用をかけてデータベースを購入した上で、アプリサーバーでバッチ処理も含めてすべて処理し、データベースのパワーを使わないのはもったいないと思います。両方の長所を活かす必要があることを人々に納得させるのは難しい。
4 に答える
3
3 層アーキテクチャで使用していないデータベースの「機能」は何ですか? おそらく、SQL を最大限に活用し、すべてのデータ管理、ページング、キャッシング、インデックス作成、クエリの最適化、およびロック機能を活用します。
議論は、私たちが「ビジネスロジック」と呼ぶものをどこに実装すべきかということだと思います。アプリ サーバーまたはデータベース ストアド プロシージャ内。
アプリ サーバーに配置する理由は 2 つあります。
1)。スケーラビリティ。DB がビジー状態になると、データベース エンジンを追加するのは比較的困難です。複数のデータベース間でデータを分割することは、非常に注意が必要です。代わりに、ビジネス ロジックをアプリ サーバー層に引き出します。これで、多くのアプリ サーバー インスタンスをすべてビジネス ロジックを実行させることができます。
2)。保守性。原則として、ストアド プロシージャ コードは適切に記述され、モジュール化され、再利用可能です。実際には、C# や Java などのオブジェクト指向言語で保守可能なコードを作成する方がはるかに簡単に思えます。何らかの理由で、ストアド プロシージャでの再利用はカット アンド ペーストによって行われるように思われるため、時間の経過とともにビジネス ロジックを維持するのが難しくなります。規律があれば、これが起こる必要はないことは認めますが、規律は現在不足しているようです.
データベース クエリ機能を最大限に活用するように注意する必要があります。たとえば、アプリ サーバー層に大量のデータをプルすることは避けます。
于 2010-06-02T05:18:39.893 に答える
2
アプリケーションによって異なります。データベースがデータベースに適した機能を実行するように設定する必要があります。何千万ものレコードにわたる 8 つのテーブルの結合は、アプリケーション層で処理したいものではありません。また、何百万もの行に対して集計操作を実行して、小さな要約情報を出力することもありません。
一方で、多くの CRUD を実行しているだけであれば、その大規模で高価なデータベースをダム リポジトリとして扱っても、大きな損失にはなりません。しかし、アプリケーションに焦点を当てた「処理」に役立つ単純なデータ モデルは、予期せぬ非効率性を忍び寄る結果につながることがあります。ノットを設計します。アプリケーション層でレコードセットを処理していることに気づきます。SQL結合を近似し始める方法で物事を調べます。最終的には、これらのものをデータベース層にリファクタリングして、桁違いに効率的に実行します...
だから、それは依存します。
于 2010-06-02T05:11:24.433 に答える
0
いいえ。ビジネス ルールの適用にも使用する必要があります。
悲しいかな、DBMS の大物は十分な能力を持っていないか、これをサポートする意思がないため、この理想を不可能にし、顧客を主要な儲けの牛に人質に取っています。
于 2010-06-02T10:46:41.433 に答える
0
次の形式のテーブルを使用して (かなり賢い人によって) 設計されたアプリケーションを見たことがあります。
id | one or two other indexed columns | big_chunk_of_serialised_data
アプリケーションからアクセスするのは簡単です。オブジェクトの 1 つ (またはセット) をロードし、必要に応じてデシリアライズするメソッドがあります。また、オブジェクトをデータベースにシリアル化するメソッドがあります。
しかし、予想通り (悲しいことに後から考えると)、そのアプリケーションの外部で何らかの方法で DB にクエリを実行したい場合が非常に多くあります! これはさまざまな方法で回避されます。アプリ内のアドホック クエリ インターフェイス (データを取得するための間接的なレイヤーがいくつか追加されます)。アプリ コードの一部の再利用。手書きの逆シリアル化コード (場合によっては他の言語); 逆シリアル化されたチャンクにあるフィールドなしで行う必要があります。
ほぼすべてのアプリで同じことが起こることは容易に想像できます。データにアクセスできると便利です。したがって、シリアル化されたデータを実際の DB に保存することはかなり嫌だと思いますが、節約が複雑さの増加を上回る可能性がある例外があります (32 ビット int の配列を保存する例)。
于 2010-06-02T05:22:19.697 に答える