多くのアプリケーションは次のモデルを使用します。
インターネットアプリケーションの場合、パフォーマンスのためにデータサーバーで単純な機能を維持する必要があるため、アプリケーションサーバーが必要です。しかし、なぜイントラネット上にアプリケーションサーバーが必要なのかわかりません。
たとえば、PostgreSQLサーバーに直接接続するAdobe AIRアプリケーションを開発できますか？多くのストアドプロシージャを持ち、厳密なアクセス許可を設定する中央のPostgreSQLサーバーをデプロイし、ストアドプロシージャを呼び出すだけで、Adobe AIRアプリケーションにデータをフェッチ（および変更）させることができると思います。
ほとんどのアプリケーションがより単純なソリューションを選択しないのはなぜですか？
一般に、PostgreSQLサーバーと直接通信するための独立したアプリケーションを入手できなかった理由はありません。一部のアプリケーションはこれを実行し、正常に動作します。
私はAdobeAIRに精通していないため、このコンテキストで可能かどうかを判断できません。原則として、PostgreSQLドライバーを入手できる場合、またはTCPソケットを使用して独自のドライバーを作成できる場合（PostgreSQLネットワークプロトコルの詳細は公式ドキュメントに記載されています）、確実に直接接続できます。
とはいえ、エンドクライアントとデータベースサーバーの間にアプリケーションサーバーの形式を設定することは、純粋にパフォーマンスのためではありません。
Webベースの開発により、SQLクエリをサーバーで制御できます。完全なSQLアクセスを公開する代わりに、クライアントが使用できる機能を公開します。後でクエリを微調整する必要がある場合（バグ、データ構造の変更など）、各ユーザーに新しいバージョンのクライアントをデプロイする必要なしに、アプリケーションサーバー上でかなり集中的にこれを行うことができます。
もちろん、このユーザーサーバープログラミングのような抽象化を直接行うこともできますが、これはすべてのアプリケーションに適しているわけではありません。これは、たとえば、別の言語でプログラムされたライブラリを使用する必要がある場合など、アプリケーションが必要とする他の機能によって異なる場合があります。一部の手続き型言語バインディングを使用できますが、常に適切であるとは限りません。たとえば、pl / Pythonは「信頼できない」言語であり（セキュリティ上の問題が発生する可能性があります）、pl/Javaには外部アドオンが必要です。
さらに、現在、すべてのアプリケーションが最終的にイントラネット用に予約されているわけではありません。多くの場合、アプリケーションの設計を開始するときに、イントラネットの使用に制限しないことが理にかなっています。
できますが...
ブラウザベースのアプリケーションについて話しているのでなければ、それはまさに多くの人がしていることです。直接またはラッパー（odbc / jdbc）を介してバックエンドデータベースと通信する従来のインストール済みクライアントアプリケーションはたくさんあります。
私は当初、直接アクセスの設計から始めましたが、Webサービスを介してDBと通信するアプリケーションサーバーに移動するとすぐに便利であることがわかりました。含まれる理由：
HTTPなどのステートレスプロトコルを介してDBと通信している場合、DBの再起動、ローカル接続の喪失、クライアントIPアドレスの変更などの処理がはるかに簡単になります。これは、リモートワーカーにとってより大きな問題です。
トランザクションは、サーバー側のトランザクションメソッドで明確に区切られ、分離されています（EJB3とコンテナー管理のトランザクションを使用しました）
より多くのコードとビジネスロジックを共有できるため、電話アプリなどの新しいクライアントを追加する方がはるかに簡単です。データベースにストアドプロシージャは非常に便利ですが、制限があり、ときどきイライラすることがあります。
一部のツール/言語には、PostgreSQLと直接通信するための組み込みツールがありませんが、XMLまたはJSON要求/応答形式でRESTfulWebサービスと簡単に通信できます。
単一のアプリケーションサーバー接続プールのみを扱っている場合は、DB管理者の方が簡単です。
主な欠点はもちろん、余分なレイヤーが余分な作業と余分なメンテナンスを意味することです。