ソフトウェア製品のバックエンドとして Access データベースを使用しています。このプログラムは、会社で約 2 年間アルファ/ベータ テストされており、その間にテーブルの 1 つが 10 万を超えるレコードでいっぱいになっていることがわかりました。これはおそらく、当社の製品が耐えられる最も過酷な使用例ではなく、5 年から 10 年後のパフォーマンスを懸念しています。
この巨大なテーブルを、数百のレコードを含む数千のテーブルに分割する論理的な方法がありますが、データベースがデータではなくテーブルで肥大化するため、この解決策がスローダウンの可能性を助長する可能性は低いと思います (私はデータベースの正式なトレーニングを受けていませんが、何を知っているのでしょうか)。
大幅な速度低下が見られる可能性があるかどうか、もしそうなら、どのソリューションが長期的にパフォーマンスを向上させる可能性が高いかについて、私よりも多くの情報を提供してくれることを期待していました。
データベースは通常、多数の行を処理するように最適化されています。問題は、何千ものほぼ同一のテーブルを維持できるかということです。（できることはほとんどありません。コーディングが複雑です）
まず、考えられるシナリオをテストします。私はあなたのデータに精通していないので、何百万行もデータベースに多すぎるかどうかはわかりません (結局のところ、これは実際のデータベースではなく MS Access です)。
テーブルのサイズに問題があり、データセットを使用頻度の低い (古い?) データと最近のデータに分割できる場合は、テーブルと table_archived (使用頻度の低い/古いレコードを含む) の 2 つにテーブルを分割することをお勧めします。 . これは、テーブルのサイズと管理の容易さの間の妥当な妥協点となる可能性があります。
問題はスキーマの問題であり、検討しているテーブルのパーティション分割が実際のデータに自然に適合しない場合、パフォーマンスの問題を悪化させるだけでなく、改善することはありません。2GBのファイルサイズの制限に関しては、データをどのようにスライスしてダイシングするかは問題ではない可能性があります-その制限に近づいている場合（50％以内だと思います）、実際にはパスのアップサイジングを念頭に置いてください。
Jet / ACEデータストアの質問ですが、数十万のレコードを持つテーブルを持つアプリは、すでにアップサイジングを評価する必要があるアプリです。何百万ものレコードを持つことが可能/可能性が高い場合、それは簡単なことだと思います-アップサイズ。
これは、要件が変化するにつれて適切な技術が変化するという理由だけで、Jet/ACEの不備によるものではありません。夫婦は結婚したときにミニクーパーがうまくいくかもしれません、そしてそれは彼らの最初の子供をうまく収容するかもしれません、しかし彼らがさらにカップルの子供を考えているなら、彼らは本当に真剣に大きな車を手に入れることを考えるべきです-何かが間違っているからではありませんミニクーパーを使用しますが、それが最適なものを超えてしまったためです。
テーブルをそれほど細分化するのはやり過ぎのように思えますが、水平パーティショニングは、多くのデータベース プラットフォームで使用されている非常に健全なパフォーマンス最適化戦略です。
MS Access を使用すると、読み取り用に適切に設計されたデータベースで、数百万行であっても、パフォーマンスが大幅に低下することはありません。また、多くのテーブルを使用しても、頻繁に圧縮して修復する場合、パフォーマンスの問題はあまり発生しませんが、より大きな問題はメンテナンスの複雑さです。少なくとも 100 万行になるまで、またはそのテーブルに対するクエリでパフォーマンスの問題が発生するまで、テーブルを分割しないでください。
問題は次のとおりです。このタイプのパーティショニングは、ユーザーが UNION で元に戻す必要があるパーティション内の複数のテーブルに対して常にクエリを実行している場合、パフォーマンスを大幅に低下させる可能性があります。あまり頻繁に検索されないアーカイブ レコードがパーティションに含まれている場合は、はるかにうまく機能します。テーブル間で頻繁にクエリを実行する必要があると思われる場合は、そこに行かないでください。
スケーラビリティの最大のハードルは、ユーザー数に関係します。数百人のユーザーが予想される場合は、非常に慎重に計画するか、クライアント サーバー データベース バックエンドを検討する必要があります。
このスレッドでは、アクセス -v- SQL サーバーの議論に入るのを避け、代わりに OP の質問に答えるだけにします。
データを分割でき、人々がそれらの分割間でクエリを実行しない場合は、テストする価値のあるオプションかもしれませんが、アクセスには 2048 の開いているテーブルの制限があるため、注意する必要があります。
ただし、何かの最大数を尋ねる必要がある場合は、間違っている可能性があると以前に言われました。これはその例だと思います。それを10個のテーブルに分割していた場合、おそらく数千個ですか？私はそれを渡します
このプログラムは、企業で約 2 年間アルファ/ベータ テストされています。
過去約 10 年間、Microsoft は人々に Access をデータベースとして使用するのではなく、さまざまなバージョンの SQL Server を使用するようにアドバイスしてきました。
5 年から 10 年後のパフォーマンスが心配です
緯度の発展を考えると - うーん - 10年はそうではないでしょう. Accessが実際に10年後もデータを保存できるかどうか、またはその間のある時点で呼び出しが「SQLサーバーのプログラム」であるかどうか、私は真剣に心配しています.
この巨大なテーブルを数百のレコードを含む数千のテーブルに分解する論理的な方法がありますが、データベースがデータではなくテーブルで肥大化するため、この解決策が速度低下の可能性を解決する可能性は低いと思います
Access は、100 万または 500 万のレコードを十分に処理できます。SQL Server は、数十億のレコードにうまく適合します。Access で問題が発生した瞬間、基本的には、深刻なデータベースに Access を使用しようとすることさえも知らなかったことに基づいて、問題が生じます。すでに述べた-MSは過去10年間、これを思いとどまらせています。
何千ものテーブルを分割するのは賢明ではありません。SQL データベースは、このために設計されていません。SQL Server Enterprise でクラスター化されたテーブルを使用しても (これを正確に実行しても)、数万のパーティションを持つことを実際にターゲットにしているわけではありません。
あなたはアクセスで死ぬ可能性が非常に高いです-アクセスは単にデータベースサーバーではありません。ふりだしに戻る。
とはいえ、Access は約 18 年前に FoxPro で取得したテクノロジーを追加して、何百万ものレコード (数千万ではなく数億) を持つテーブルを簡単に処理できるようにしたので、現時点では非常に安全です (しようとする悪夢を除いて)。そのようなものでデータベースの修復、バックアップなどを行うか、ネットワーク共有を介してマルチユーザーアプリケーションを実行するという悪夢さえあります。
SQL Server, otoh, 現在、約 6 億 5,000 万レコードのテーブルがあり、データの読み込みが開始される次の 6 か月で約 100 億または 200 億に増加しますが、これまでのところ問題はありません。