結果の検索と表示 (書き込み操作なし) に使用される Flex アプリケーションの場合、現在リレーショナル データベースにデータを格納していますが、アプリを介して DB にクエリを実行するのではなく、夜間にデータの書き込みを行っています。関係、XML ファイルに。
次に、Flex を使用してその XML ファイルをロードし、カスタム オブジェクトに解析して、必要に応じてそれらのオブジェクトを「クエリ」します。
これは非常にうまく機能します。基本的に、これらのオブジェクトの ArrayCollection を検索条件に基づいてフィルタリングします。
たとえば、DB のクエリに対して、全文検索はこのシナリオでは非常に高速です。
しかし、いくつかの潜在的な欠点は何ですか? このアプローチはどの程度有効ですか? どんな考えでも大歓迎です。
前もって感謝します。
簡単な答えは: ... 申し訳ありませんが、簡単な答えはありません。
長い答えは次のとおりです。アーキテクチャの決定には、常に何らかのトレードオフが伴います。アプリケーションの正しい決定は、ほとんどの場合、コンテンツとシステムの全体的な設計に依存します。
私が確かに言える唯一のことは、あなたが今していることは、懸念の明確な分離を妨げているということです.
たとえば、サーバーで検索を行った場合、クライアントが知らないうちにデータベースのフィールド名などを変更する可能性があります。これは、実際のデータ出力を「古い」モデルに一致するように調整できるためです。クエリは完全に異なっていました。クライアントはデータの表示を担当し、サーバーはデータの永続化と取得を担当します。これは、大規模なチームで開発する場合、またはアプリケーションが長時間実行され、複雑なトランザクションを持ち、および/またはエンタープライズ シナリオなどで頻繁に動作を変更する場合に、おそらく必要となるものです。ハードウェアのコストは大企業にとって最も差し迫った懸念事項ではないため、これらのシナリオでは通常、サーバーへの負担が大きくなり、より強力なハードウェアが必要になることが考慮されます。
完全なデータ セットの大きさによっては、ネットワークの負荷も大幅に軽減されます。これは、すべてのデータ セットをクライアントに転送する必要はなく、関連する結果のみを転送する必要があるためです。そのため、サーバーのネットワーク接続が制限されている場合、またはユーザーの接続が遅い傾向にある場合、これはおそらく良い考えです。
一方、クライアントアプリ内で検索してクエリを実行すると、説明したように、データベースと Web サーバーの負荷が軽減されます。これは必ずしも悪いことではありません。特にサーバーの容量とパフォーマンスが制限されている場合はそうです。重要です。
ただし、全体的なネットワーク トラフィックの増加は別として、クライアント コンピューターへの依存度が高まることも意味します。a) 検索を処理するのに十分な速度が必要であり、b) 更新されたアプリを常に (再) 展開する必要があります。データモデルが少しでも変更されるたびに、ユーザーに。これはエラーの主な原因である可能性が非常に高いため、何らかのバージョン チェックを実装して、古いクライアントがサーバーに接続しないようにしたり、ブラウザーのキャッシュを無効にしたりする必要があります。
したがって、最終的には、長所と短所を比較検討してから、ニーズに最適なソリューションを決定する必要があります。3 つ目のオプションとして、 Luceneなどの専用検索エンジンの使用を検討することもできます。