私は現在、各ネイティブ.netクライアントインスタンスがSQLデータベースに接続できる単純なマルチクライアントセットアップを計画しています。マルチクライアントSQLアクセスアーキテクチャのベストプラクティス
しかし、私の心配はアーキテクチャです。セットアップが数百のクライアント接続に増えた場合、どのようなアーキテクチャから始めるのが最適でしょうか？
セットアップ全体が閉じたネットワークにとどまります。
A：クライアントとSQL DBの間にハンドラサービスを実装して、後でロードのバランスを改善しますか？
B：クライアントをDBに直接接続しますか？
あなたの思考や推薦を大いに楽しみにしています。
私は実際にdbを直接公開することを嫌っています.dbの変更にはクライアントの更新が必要になることがあります。私は、必要な操作とオブジェクトだけを公開し、その間にサービスを置く（REST、SOAPなど）。次に、サービスの定義とクライアントが変更する必要がないパフォーマンスのためにいくつかのデータを非正規化する必要があるとわかった場合。
これはまた、（sprocs以外の）サーバー上にロジックを持たせることができ、何かを修正または改善する必要がある場合、常に複数のクライアントよりもサーバーを更新する方が簡単であることを意味します。キャッシングもうまく機能し、DBのロードに役立ちます。
DB以外の場所からデータを取得する必要がある場合があります。たとえば、フルテキスト検索が必要な場合は、Lucenceを使用してリレーショナルDBから検索します。他のサービスやアプリから追加データを取得する必要があるかもしれません。ここでもサーバは、クライアントが知っているか気にすることなく、これをすべて行うことができます。
また、db接続がずっと少なく、サービスとdbが同じサブネット上にあるため、待ち時間が短くなければなりません。私はあなたの接続がどれほど良いのか分かりませんが、HTTPを使ったRESTのようなものは、おそらく生のdbクエリーよりも寛容になるでしょう。
だから私はクライアント - >サーバー - > dbに行くだろう。