難しい質問ですが、私の経験を共有し、それが役立つかどうかを判断させていただきます。
ソースファイルの処理からの出力を保持する必要があり、それを使用して派生データの複数のビューを生成する場合は、組み込みデータベースの使用を検討できます。組み込みデータベース（IMHO）を使用する理由：
- RDBMS機能（ACID、関係、外部キー、制約、トリガー、集約など）を利用するため
- 柔軟な方法でデータをエクスポートしやすくするため
- 処理されたデータへの外部クライアントへのアクセスを有効にするには（既知の形式）
- 表示の準備をするときにデータをより柔軟に変換できるようにするため
決定を下す際に考慮すべき要素：
- ターゲットプラットフォーム（Windows、Linux、Android、iPhone、PDA）は何ですか？
- どのような技術基盤ですか？（Java、.Net、C、C ++、...）
- どのようなリソースの制約が予想されるか、または設計する必要がありますか？（RAM、CPU、HDスペース）
- どのような運用上の動作を考慮する必要がありますか（ネットワークに接続されている、切断されている）？
一般的な最新のデスクトップには、ほとんどの操作を処理するのに十分な予備容量があります。eeePC、PDA、およびその他のポータブルデバイスでは、そうではない可能性があります。組み込みデバイスでは、そうではない可能性が非常に高いです。使用する言語には、メモリ管理に役立つ機能が組み込まれている場合があります。これらの機能を利用できる場合があります。接続性の側面（ステートフル/ステートレスなど）は、任意の時点で実際にメモリに保持する必要がある量に影響を与える可能性があります。
非常に大きなファイルを処理している場合は、ストリーミングプロセスのアプローチを検討して、一度にデータ全体のごく一部しかメモリに保存しないようにすることができますが、それは実際に使用する必要がある（または使用してはならない）という意味ではありません。組み込みデータベース。ストレートテキストまたはバイナリファイルも同様に機能します（レコードベース、列ベース、行ベースなど）。
一部のデータベースでは、データが保存された後、データをより効果的に操作できるようになります。これはエンジンによって異なります。ベースファイル（つまり、元のソースから最初に生成するファイル）に多くの集約が必要な場合は、RDBMSエンジンがロジックを単純化するのに非常に役立つことがわかります。他のオプションには、ベーストランスフォームを構築し、それを処理するための追加のステップを追加して、特定のビューごとに他の一時ストアに入れ、ターゲット（レポート？）形式にレンダリングするために処理することが含まれます。
ただの意識の流れの反応-それが少し役立つことを願っています。
編集：
さらに明確にするために、組み込みデータベースがあなたが取りたい方向であるかどうかはわかりません。グラフをレンダリングするために、ある種の単純化された仮定を行うか、セグメンテーションなどの方法を調査する必要があります（グラフのセクションをレンダリングしてから、次のセクションをレンダリングする前に出力をキャッシュします）。