これはアプリケーションに依存していることを理解しています。問題のツールは、固定幅のテキスト ファイルを反復処理し、Access テーブルで指定された一連の検証規則と照合します。標準ファイルをすべての検証チェックで実行すると、現在のツールを使用して最大 1 時間かかる場合があります。
検証ルール テーブルを SQL Server に移行し、コードをスタンドアロンの VB.Net アプリケーションにリファクタリングすることができました。
パフォーマンスの向上が期待できる理由はありますか?
それは、開発者だけでなく、非常に多くのことに依存します。私は常に、最先端の技術を持った貧弱な開発者よりも、貧弱な技術を持った優秀な開発者の方が、より良い製品を生み出すことができると考えています。
移行を決定する上で重要な変数は多数あります。例えば:
あなたの投稿で述べたように、危機に瀕している多くの変数があるため、急いで移行するつもりはありません。私を信じてください、私は以前にそれを見たことがあり、現在の状況を注意深く分析しない限り、大幅な改善が得られるという保証はありません.
移行以外に考えられるもう 1 つのことは、自動化です。私は、早朝に多くのプロセスを実行する RAD チームで働いていました。Windows のスケジュールされたタスクを使用して、特定の時間にデータベースを起動し、ファイルを検索してインポートし、それらを処理しました。一部のプロセスには 1 時間かかったかもしれませんが、朝オフィスに入る前にすべて完了していたので、完了までに 1 時間かかったとしても気にしません。
あなたが言ったように、本当の答えは「場合によります...」ですが、あなたが説明した処理のタイプに基づいて、そのようなことを行うことで大きなパフォーマンスの違いが見られるとは思わないと思いますAccess VBA で作業し、スタンドアロン .NET アプリで同じ種類の作業を行います。
バックエンド データベースを ACE/Jet から SQL Server に切り替えると、関連するデータの量と、一部の検証をアプリケーション レベル (VBA または .NET) からデータベース レベルにプッシュダウンできるかどうかによって、パフォーマンスが大幅に向上する可能性があります。(SQLサーバー)。ただし、バックエンドを SQL Server に移行するために、必ずしもアプリケーション コードを VBA から .NET に完全に移植する必要はありません。あなたの特定の要件に応じて...
.NET でパフォーマンスを向上させる最善の方法は、ルールをメモリ (おそらくルール オブジェクトのコレクション) に取り込み、プロセスからデータベースのボトルネックを取り除くことです。
Access テーブルからルールを繰り返し取得すると、パフォーマンスが向上することがありますが、パフォーマンスの問題を引き起こしているのは、検証の実行方法である可能性があります。.NET を使用すると、テキスト ファイルをメモリに読み込んだ後、テキスト ファイルに対して並列操作を実行できるため、パフォーマンスが向上する可能性があります。ただし、要件をすべての行に実装できる場合、最大の改善点はおそらく、データをテキスト ファイルから T-SQL で実装された SQL Server にプルすることだと思います。これは、データ セット全体の操作に最適化されています。行ごとではなく。または、外部ツールからそれらを実装します (.NET は VBA よりも高速です。はい)。
テキスト ファイルを SQL にプルできない/したくない場合は、.NET でそのファイルをメモリにプルし、マルチスレッド ループを使用して操作し、ルールに対してテストできることを検討してください。もちろん、有益なスレッドの数には制限がありますが、4 つのプロセッサがある場合は、それらを使用することもできます。