MS Accessのバイパス2GBファイルサイズ制限
MS Accessを作成しています*.accdb複数のテーブルと特定の関係を持つデータベース。
このデータベースは、数百万のオーダーのオーダーを含む別のシステムへの一度のデータ転送に使用されます。 200万のダミーエントリを使用したテストでは、すでにファイルサイズが約1.8 GBに達しています。 MS Accessにはデータベースファイルごとに2GBの制限が組み込まれているため、この制限を回避するための解決策を探しています。
これまでに2つのアイデアを思いつきました。
データベースを2つのファイルに分割し、関連するテーブルのエントリの独立性を考慮して、file1からfile2への移行中にインデックス作成を続行します。
file1_table1 (indices 1..1000) file2_table1 (indices 1001..N)1つのマスターインターフェイスファイルを使用して、テーブルを別のファイルにエクスポートする
file1_table1 file2_table2 file3_table3 masterfile (linking table1..3 and creating table relationships)
コンセプト、パフォーマンス、使いやすさに関するこれらのアイデアについて、またはこれについて他のアイデアがある場合は、フィードバックをお願いします。
MS Accessに固執したいことに注意してください。SQLデータベースは1回限りのトランスポートにのみ使用されるため、SQLデータベースを構築するのはやり過ぎです。
データはいくつかのソース（MS Access .accdb、Excel Sheets *.xlsx、区切られたファイル*.csv）を分析し、マージして、一時的な使い捨てのMS Accessデータベースとして準備し、SQLに基づいた作業用データベースに変換します。したがって、これは従来のETLプロセスです。
「Compact and Repair」コマンドは役に立ちません。これは実際には大量のデータであり、大量の操作ではなく大量のジャンクを残しているためです。 「Accessデータベースを分割する」手順では、クエリ/フォーム/レポートをテーブルを含むバックエンドファイルから分離しているように見えますが、テーブル自体を分割する必要があるため、分割ファイル間の一貫性の問題が残ります。これは、インターフェース（フロントエンド）とデータバックエンドの分離に関する問題ではありません。データ量が多いため、データバックエンド自体を分割する必要があります。
Accessデータベースの組み込みの制限を回避することはできません。ただし、複数の*.accdbファイル間でデータベースオブジェクトを分割し、それらを適宜参照するなどの組み込み機能を使用して、組み込みの制限を回避することができます。
すべてのデータベースオブジェクトとデータを含む、Access 2016データベース（.accdb）の合計サイズ：
2ギガバイト、システムオブジェクトに必要なスペースを差し引いたもの。
注：他のAccessデータベースのテーブルにリンクすることで、このサイズ制限を回避できます。複数のデータベースファイルのテーブルにリンクできます。各ファイルのサイズは2GBまで可能です。ヒント：データベースのサイズを縮小する方法の詳細については、 を参照してください。最適化と修復を使用して、データベースファイルの問題を防止および修正してください。
さらに一歩進んで、すでに述べたように、データとインターフェースを分割することもできます。
複数の人がネットワークを介して共有するデータベースを分割することを検討してください。共有データベースを分割すると、パフォーマンスが向上し、データベースファイルが破損する可能性が低くなります。
データベースを分割した後、バックエンドデータベースを移動するか、別のバックエンドデータベースを使用するかを決定できます。リンクテーブルマネージャーを使用して、使用するバックエンドデータベースを変更できます。
これはMicrosoft Accessであるため、 [〜＃〜] [〜＃〜] が機能する可能性がある、または機能しない可能性がある別のソリューションを試すのではなく、サポートされているオプションを使用することをお勧めします。
以前は、インターフェース（FE）とデータ（BE）が分割されたアプリケーションがありました。ファイルサーバーでホストされている場合、パフォーマンスに顕著な違いはありません。ただし、BEが2 GBに達すると、書き込みによってBEが破損し、データが回復不能になったため、SQL Server Expressに切り替えてから、後でSQL Serverに切り替えることにしました。異なるテーブルを含む複数のBEファイルにアクセスしても、パフォーマンスに大きな影響はないと思います。しかし、ファイル共有にBEを置くことは、一般的にそれらをローカルに保存するよりも遅くなります。
バックエンドをSQL Serverに移行することを強くお勧めします。
テーブルは SQL Serverにリンクされたテーブル を介してアクセスからアタッチできます。
このアプローチの利点は、アクセスファイルの制限を回避するためにスケールアップしながら、アクセスで行ったすべての作業を利用できることです。
アクセスからのインポートとアップスケーリングでさえ 支援するウィザード があります。
パフォーマンスは、SQLファイル、テーブル、インデックスの設計に直接影響されます。しかし、大まかに言えば、アクセスよりも優れていないとしても、同様に実行する必要があります。基本的なヒント：
適切なファイルサイズのユーザーデータベースを作成し、ファイルの増加量を100Mbまたは1Gbに設定します。
各テーブルにSQLサーバーで定義された主キーがあることを確認します。一意のインデックスだけではありません。アクセスでは、リンクされたテーブル定義で定義された主キーがないと、SQLテーブルを更新できません。
アクセス自動番号に相当するのは、ID列です。重複するステージングテーブルがある場合、ID列をpkeyとして追加する価値があります。
SQLインスタンスにアクセスできない場合は、SQL Expressまたは開発者をPCにインストールできます。
SQLサーバーに慣れていない場合は、学習曲線が少しありますが、努力する価値は十分にあります。
SQLには、多くのオプションを提供する強力なツールがいくつか付属しています。 SSISの学習はこのプロジェクトには多すぎるかもしれませんが、SSMSのインポートウィザードで多くを達成し、再利用するパッケージを保存できます。
これが1回限りのトランスポートである場合、なぜAccessを使用するのですか？データを区切られた（カンマ/タブ/パイプ）ファイルに入れ、それで完了です。ほとんどのシステムはそのフォーマットからインポートします。