１USERあたり1000件くらいと言う事でしたので、新規ユーザーにみてもらいたいデータが決まっているようであれば、元の①.qvwのスクリプトの中に、ユーザー単位でCSV出力するスクリプトを記載すると、新規ユーザーへライセンスを渡さなくてもCSVで見てもらえるので、ライトなユーザーや一時的に一部データのみを利用するユーザーにはこのような方法で逃げるのもありだと思います。
リロード時間の件は、私は利用当初シンセティックキーが出来るようなテーブル構成をしていて、リロードにかなり時間を要していましたが、以下のような方法をとる事で、かなり短縮できました。
①合成キーを用意して、シンセティックキーをつくらないようにする
たとえば、日付(2020/4/１)とCD(1001)のふたつがリレーションに利用される状態の場合は、ふたつを合わせてしまって'202004011001'という合成キーにしてしまいます。
こうすると、リロードの恩恵だけでなく、ファイル内の動作も速くなります。
②過去データはQVD化して保存し、更新が発生する期間のみDBやCSVなどから取得する。
とくにCSVはファイル数が多くなるとデータ量に対して読込に時間を要するので、取得先フォルダからデータを取得してQVD化したら、別のアーカイブフォルダへ移すといった運用をすると、かなり速度が改善されます。
とくにQVDの読込速度は強烈です！DBからの読込速度と比べると、10～100倍の早さです。
その他、ファイル内のパフォーマンスをあげる場合、リレーションキーに利用している項目をAutoNumber関数を使って数値の連番に置き換えると、これも効果があります。ファイルサイズも少し小さくなります。
ただデメリットもあって、リロード時間が増えます。億件のデータを利用している場合は、やめた方が良いケースもありますので、このあたりはリロード時間とファイルの動作パフォーマンスのバランスで判断するしかないです。
DBやアクセスなど、データの保存先でも処理が出来るデータ等であれば、ダイレクトディスカバリーという方法もあって、ファイル内にはデータを取り込まずに、期間やCDなど、データを検索する情報のみ取得しておいて、ユーザーがリストボックスで絞り込んだ際に、直接DBへデータを見に行って計算処理を行うといった事も可能です。こうする事で、常にタイムリーな情報を使う事が可能です。
ただこの場合の処理は、QVではなく取得先のDBのパフォーマンスに影響を受けるので、場合によっては処理が遅くなるといったデメリットもありますが。。。
