[解決済み] なぜ開発者はデータベースへの直接接続ではなく、ウェブサービスを使うべきなのでしょうか？[クローズド］

質問

私は、データベースへ直接接続するのではなく、Web サービスを介してリモート データベースへ接続する理由のトップ 10 リストが欲しいのです。これは現在社内で議論されていることで、私はウェブサービスを支持していますが、議論には負けています。私はWCF/ウェブサービスについて基本的なことは理解していますが、他の誰も理解していません。私たちは今後やりたいことは何でもできますが、今選択したものには固執する必要があります。

これが私が思いついたものです。他に何かありますか?

1. WCF ウェブサービスは、正しく構成されていれば、より安全にすることができます。
2. DBへの変更は、サービスレベル（設定ファイルまたはサービスのリコンパイル）でしか行う必要がありません。
3. 一度セットアップしてホスティングすれば、ウェブサービスは簡単に利用できるようになります。

どのように解決するのですか？

1. セキュリティを確保する Webサーバ/アプリのユーザ以外にはDBアクセス権を与えないようにする。

   これは、大量のユーザがいる場合に特に重要です。DB側でのユーザーやロールのメンテナンスの手間を省くことができます。

2. DBの負荷軽減。ウェブサービスはDBから取得したデータをキャッシュすることができる。

3. データベースコネクションプーリング(hat/tip @Dogs)。

   ウェブサービスは恒久的に開かれたDB接続の小さなプールを使うことができます。これはさまざまな方法で役に立ちます。

   • DB 接続プールは、データベースサーバー側で制限されます。

   • 新しいDB接続を開くことは、非常にコストがかかります（特にデータベースサーバに）。

4. フォールトトレランスの能力 - サービスは、フェイルオーバーの詳細をサービス消費者が実装することなく、プライマリ/DRデータソース間で切り替えが可能です。

5. スケーラビリティ - サービスは、リソースピッキングの詳細をサービスコンシューマに実装させることなく、複数の並列データソース間でリクエストを分散させることができます。

6. カプセル化。サービス利用者に影響を与えることなく、基盤となるDB実装を変更することができます。

7. データの充実 (これには、クライアントのカスタマイズからローカライズ、内部化まであらゆるものが含まれます)。基本的にこれらのどれもが有用かもしれませんが、どれもがデータベースへの大きな負荷であり、しばしばDB内部で実装するのは非常に困難です。

8. 適用されるかもしれないし、されないかもしれない - ある種のアーキテクチャの決定は、DBへのアクセスに優しくはありません。 たとえば、Unix 上で動作する Java サーバーはデータベースに簡単にアクセスできますが、Windows PC 上で動作する Java クライアントはデータベースを意識していませんし、そうであってほしいとも思っていないでしょう。

9. 移植性。クライアントはすべて同じプラットフォーム/アーキテクチャ/言語上にあるとは限りません。それぞれに優れたデータアクセス層を再作成することは、Webサービス用のコンシューマ層を構築するよりも困難です（前述のフェイルオーバーなどの問題を考慮しなければならないため...）。

10. パフォーマンスチューニング。クライアントが（あらかじめ用意されたストアドプロシージャではなく）独自のクエリを実行すると仮定すると、最適ではないクエリを使用し始めることは100%確実です。また、ウェブサービスが許容されるクエリのセットを制限している場合、データベースのチューニングに大きく役立ちます。このロジックはストアドプロシージャにも同様に適用可能であり、Webサービスに固有のものではないことを付け加えておかなければなりません。

良いリストもあります を参照してください。データベースアクセスのカプセル化。アジャイルなベストプラクティス(A Agile "Best" Practice)」。

はっきりさせておきたいのですが、これらの問題のいくつかは、すべての状況に適用できるわけではありません。ポータビリティを気にしない人もいます。DBのセキュリティについて心配する必要がない人もいます。DBのスケーラビリティについて心配する必要がない人もいます。