私の経験では、SQL Serverはこれに最適であり、SQL Serverには、MS-Accessよりも優れたパフォーマンスが期待できます。一般的に、より多くの最適化方法を自由に使用できます。
あなたが言ったように、私はおそらく先に進んで、このようなものをSQL Server Expressに入れ、うまくいけば、使用できる最高のマシンにインストールします（ただし、2GBのRAMしか言及していません）。1つのことだけを表す限り、1つのテーブルを使用します（不条理な例として、パイロットのフライトログとソフトウェアエラーログが同じ「ログ」テーブルに含まれないと思います）。パフォーマンスを確認してください。問題がある場合は、SQLServerのエディションで利用できる最適化手法をいくつでも使用してください。
これが私がおそらく最初にそれを行う方法です：
ログテーブルでPKを使用する場合は、クラスター化されていない主キーを使用してテーブルを作成します-私は通常、ID列を使用して、イベントの保証された順序を提供し（重複する日時とは異なり）、ログ挿入の失敗の可能性（IDの欠落）を表示します）。メインの日時列にクラスター化インデックスを設定します（すでに月ごとに別々のテーブルに分割されているとおっしゃっていたので、この方法でもクエリを実行すると思います）。このテーブルで定期的に実行するクエリがいくつかある場合は、必ずそれらのビューを作成しますが、単にそうするだけでスピードアップすることは期待できません。テーブルのインデックス作成を検討することをお勧めしますそれらのクエリのwhere句に基づいています。ここで、SQLサーバーにこれらのクエリを効率的に実行するために必要な情報を提供します。
クエリ、インデックスを最適化し、可能な限り最小のデータ型（特にインデックス付きの列）を使用し、適切なハードウェアで実行しても目的のパフォーマンスを得ることができない場合は、パーティション化されたビュー（何らかの形式の継続的なビューが必要）を試す時期が来ている可能性がありますメンテナンス）またはテーブルのパーティション化。残念ながら、SQL Server Expressでは、パーティショニングで実行できることが制限される場合があり、SQLServerのより機能が充実したエディションに移行する必要があるかどうかを判断する必要があります。EnterpriseEvaluationまたはDeveloperエディションでいつでもパーティショニングをテストできます。
アップデート：
ほとんどの場合、イベントタイプをフィルタリングし、その数を数える必要があります。
過去のログは変更されないため（過去の売上データのようなもの）、このシナリオでは過去の集計数を保存することがよく使用される戦略です。毎月のカウントを保存するだけのテーブルを作成し、ある種のスケジュールされたジョブを使用して、月に1回（または週、日など）新しいカウントを挿入できます。SQL Serverは、日時列のクラスター化インデックスを使用して、ライブテーブルから今月の数値をはるかに簡単に集計し、それらを保存された集計に追加して、合計数などの現在の値を表示できます。