1

私の要件を述べさせてください。非常に動的なレポートのニーズを満たすソリューションを設計しています。これらのデータは、今のところ sqlite データベースで生成されているため (キューブと呼ばれています)、サーバー マシンには多数のキューブがあります。これらのキューブで作成されたチャートは、テレリック レポート エンジンで開発されています。これらは、キューブ データにアクセスし、UI 用のチャートを準備する dll のセットです。変わらないのはスキーマです。すべてのタイプのキューブには特定のスキーマがあり、それに固執します。

時々新しいチャートがあります。新しいチャートやチャート テンプレートを 1 日おきに含めるために、新しいフレームワークの一部にしたくありません。そのため、別のサービスでホストし、サービスを呼び出してフレームワークからデータを取得し、それを処理してグラフを作成することを計画していました。

ここでの問題は、ワイヤを介して転送されるデータのサイズです。これは、チャート化のためにビジネス ロジックが適用される前に巨大なサイズになる可能性があります。

それで、それをより「モジュラー」でスケーラブルにするが、どうにかして実行可能にするための提案は何でしょうか。つまり、これは良いアプローチですか？

4

1 に答える 1

0

別のシステムの「下から」データベースを読み取って、その動作をバイパスすることを計画しているようです。これは悪い考えを示す傾向がありますが、必要な場合もあります。

大量のデータを「ネットワーク上で」読み取ってから処理する必要がある場合、レポート要件とは別に、データを抽出して処理する何らかのタイプの「同期」プロセスが必要なように思えます。その後、レポートは処理されたデータのみで機能し (つまり、パフォーマンスが向上します)、データを抽出してレポート用に処理するために必要な限り、同期プロセスに時間がかかる場合があります。これには、作成する新しいレポート専用の別のデータベース/ストレージ領域が必要になる可能性があります。

可能であれば、意図したとおりにシステムを操作し続けることをお勧めします。つまり、新しいレポートやデータ「キューブ」などがそのシステムに組み込まれます。1 日おきに新しいレポートを作成する予定の場合、検討しているソリューションと、既に稼働しているソリューションによって、どのようなメリットがありますか?

于 2012-08-17T01:43:38.213 に答える