MS Accessデータベースエンジンテーブルの最大行数？
MS Accessデータベースエンジンは、2GBの最大ファイルサイズを許可するように「抑制」されている（または、おそらく内部で4KBデータページの2の累乗未満に制限されるように配線されている）ことがわかっています。しかし、これは実際にはどういう意味ですか？
これを測定するために、MS Accessデータベースエンジンテーブルに挿入できる最大行数を教えてください。
テーブルの定義を満たすには、すべての行が一意である必要があるため、一意の制約（例：PRIMARY KEY、UNIQUE、CHECK、データマクロなど）は必須です。
編集：私は理論的な制限があることに気づきますが、私が興味を持っているのは、実用的（必ずしも実用的）ではなく、現実の制限です。
これが私の試みです：
キーのない単一列（INTEGER）テーブルを作成しました。
CREATE TABLE a (a INTEGER NOT NULL);
1から始まる順序で整数を挿入しました。
65,632,875行を挿入したときに（何時間もかけて）任意に停止しました。ファイルサイズは1,029,772KBでした。
ファイルを圧縮して、わずかに1,029,704 KBに減らしました。
PKを追加しました：
ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);
これにより、ファイルサイズが1,467,708 KBに増加しました。
これは、最大値が約8000万マークのどこかにあることを示唆しています。
いくつかのコメント：
Jet/ACEファイルはデータページに編成されています。つまり、レコードの境界がデータページと揃っていない場合、ある程度のスラックスペースがあります。
行レベルのロックは、データページごとに1つのレコードを強制するため、可能なレコードの数を大幅に削減します。
Jet 4では、データページサイズが（Jet 3.xの2KBから）4KBに増加しました。 Jet 4は、Unicodeをサポートする最初のJetバージョンだったので、1 GBの2バイトデータ（つまり、1,000,000,000 2バイト文字）を格納でき、Unicode圧縮をオンにすると、2 GBのデータを格納できました。したがって、レコード数は、Unicode圧縮がオンになっているかどうかに影響されます。
Jet/ACEファイルのどの程度のスペースがヘッダーやその他のメタデータによって占められているか、正確にどれだけのスペースインデックスストレージが占めているかはわからないため、理論的な計算は常に実用的な範囲で行われます。
最も効率的なストレージを実現するには、Access UIではなくコードを使用してデータベースを作成する必要があります。Accessは、Jetが必要としない特定のプロパティを作成するためです。 Accessのデフォルトに設定されたプロパティは通常まったく設定されないので、これらの多くがあると言っているわけではありません（プロパティは、デフォルト値から変更した場合にのみ作成されます-これは、フィールドの循環によって確認できますプロパティコレクション、つまり、Accessテーブルデザイナのフィールドにリストされているプロパティの多くは、設定されていないため、プロパティコレクションにはありません）が、Jet固有のデータ型（ハイパーリンクフィールド）に限定することができます。たとえば、アクセス専用です）。
Rnd（）を使用してタイプバイトとして定義された4つのフィールドに4つのフィールドの複合PKを入力するためにこれをいじくり回して1時間無駄にしました。2GBの重要な部分まで取得するのに十分なレコードを追加するのに永遠にかかりました。 200万件を超えるレコードでは、ファイルは80MB未満でした。私はちょうど到達した後、ようやくやめました 70万 7 MILLIONレコードと184MBに圧縮されたファイル。 2GB近くに到達するのにかかる時間は、私が投資したいと思っている以上のものです。
他の人が述べたように、それはあなたのスキーマとインデックスの数の組み合わせです。
ある友人は、2 GBの上限に近づいたMDBに約1億の過去の株価、毎日の終値を持っています。
彼は、Microsoftナレッジベースの記事にあるいくつかのコードを使用してそれらを削除しました。彼が使用していたサーバーが最初の100Kレコードの後に彼を遮断しなかったので、私はむしろ驚いた。
彼はどんな記録も一秒未満で見ることができた。
Accessで最後に作業してから数年が経過しましたが、以前よりも大きなデータベースファイルを使用すると、小さなファイルよりも多くの問題が発生し、破損しやすくなりました。
データベースファイルが1人のユーザーのみがアクセスしているか、堅牢なネットワークに格納されている場合を除き、2GBのデータベースサイズの制限に達する前に問題が発生することがあります。
ここでは必ずしも理論上の制限について話しているのではなく、最大2GBのファイルサイズとデータベーススキーマの実際の制限について話している。
- あなたのデータベースは単一のテーブルですか、それとも複数ですか？
- 各テーブルにはいくつの列がありますか？
- データ型とは何ですか？
スキーマは、行数に基づいて、保持できる行数を決定します。
一部の企業ユーザーによる統計分析のために、MS-SQLデータのエクスポートを格納するためにAccess MDBを使用しました。これらのケースでは、コアテーブル構造をエクスポートしました。通常は、1行あたり100バイトから1行あたり8000バイトを超える20〜150列の4つのテーブルです。これらの場合、数十万行のデータにぶつかることになるため、出荷するMDBごとに許容されます。
だから、私はあなたのスキーマがなければこの質問に答えがあるとは思いません。
4つの大きなDb2テーブルを操作するとき、制限を見つけただけでなく、4つのテーブルすべて（900,000行以上）を1つの大きなテーブルに追加できると考えていた上司に、ひどく見えました。実際の結果は、テーブル（正確に34列-30テキストと3整数）を何回試しても、「データベースを認識できない形式で開けないか、ファイルが破損している可能性があります」という不可解なメッセージを出力するというものでした。ボトムラインは1,500,000レコード未満であり、34行で1,252,000を少し超えています。
実用的=「実際に役立つ」-したがって、あなたが得る最高のものは逸話的です。それ以外はすべてプロトタイピングとテスト結果です。
私は他の人に同意します-「レコードの最大数」の決定はスキーマに完全に依存しています-＃テーブル、＃フィールド、＃インデックス。
別の逸話：私は最近、それぞれ36および85フィールドの2つのプライマリデータストア（テーブル）で1.6GBのファイルサイズに達し、いくつかのサブセットコピーが3つの追加テーブルにあります。
データが一意であるかどうかは誰が気にしますか-コンテキストがそれを示している場合にのみ重要です。重複がインデクサーによる処理に影響しない限り、データはデータです。
1.6GBを構成する合計行数は1.72Mです。
それはすべて異なります。理論的には、4バイトのデータ型を持つ単一の列を使用します。 30万行を格納できます。しかし、何かを行う前であっても、データベースにはおそらく多くのオーバーヘッドがあります。 1.000.000行になる可能性のある場所をいくつか読みましたが、やはり、すべてに依存します。
データベースをリンクすることもできます。ディスクスペースのみに制限する。