15

MS Accessデータベースエンジンは、2GBの最大ファイルサイズを許可するように「調整」されていることがわかっています（または、内部的に配線されて、4KBデータページの2の累乗未満に制限されている可能性があります）。しかし、これは実際にはどういう意味ですか？

これを測定するために、MSAccessデータベースエンジンテーブルに挿入できる行の最大数を教えてください。

テーブルの定義を満たすには、すべての行が一意である必要があるため、一意の制約（PRIMARY KEY、、、、データマクロなど）が必要です。UNIQUECHECK

編集：私は理論的な限界があることを理解していますが、私が興味を持っているのは実際的な（そして必ずしも実用的ではない）、現実の限界です。

4

8 に答える 8

13

Some comments:

  1. Jet/ACE files are organized in data pages, which means there is a certain amount of slack space when your record boundaries are not aligned with your data pages.

  2. Row-level locking will greatly reduce the number of possible records, since it forces one record per data page.

  3. In Jet 4, the data page size was increased to 4KBs (from 2KBs in Jet 3.x). As Jet 4 was the first Jet version to support Unicode, this meant that you could store 1GB of double-byte data (i.e., 1,000,000,000 double-byte characters), and with Unicode compression turned on, 2GBs of data. So, the number of records is going to be affected by whether or not you have Unicode compression on.

  4. Since we don't know how much room in a Jet/ACE file is taken up by headers and other metadata, nor precisely how much room index storage takes, the theoretical calculation is always going to be under what is practical.

  5. To get the most efficient possible storage, you'd want to use code to create your database rather than the Access UI, because Access creates certain properties that pure Jet does not need. This is not to say there are a lot of these, as properties set to the Access defaults are usually not set at all (the property is created only when you change it from the default value -- this can be seen by cycling through a field's properties collection, i.e., many of the properties listed for a field in the Access table designer are not there in the properties collection because they haven't been set), but you might want to limit yourself to Jet-specific data types (hyperlink fields are Access-only, for instance).

I just wasted an hour mucking around with this using Rnd() to populate 4 fields defined as type byte, with composite PK on the four fields, and it took forever to append enough records to get up to any significant portion of 2GBs. At over 2 million records, the file was under 80MBs. I finally quit after reaching just 700K 7 MILLION records and the file compacted to 184MBs. The amount of time it would take to get up near 2GBs is just more than I'm willing to invest!

于 2009-08-03T21:32:03.137 に答える
11

これが私の試みです：

キーのない単一列 ( INTEGER) テーブルを作成しました。

CREATE TABLE a (a INTEGER NOT NULL);

1 から始まる整数を順番に挿入します。

65,632,875 行が挿入されたときに (何時間もかけて勝手に) 停止しました。ファイル サイズは 1,029,772 KB でした。

ファイルを圧縮して、わずかに 1,029,704 KB に縮小しました。

PKを追加しました：

ALTER TABLE a ADD CONSTRAINT p PRIMARY KEY (a);

これにより、ファイル サイズが 1,467,708 KB に増加しました。

これは、最大値が 8000 万程度であることを示唆しています。

于 2009-08-06T09:43:51.527 に答える
5

他の人が述べているように、それはスキーマとインデックスの数の組み合わせです。

友人は、2 Gb の制限に近づいた MDB で、約 1 億の過去の株価、毎日の終値を持っていました。

彼は、マイクロソフトのナレッジ ベース記事にあるコードを使用してそれらを取り出しました。彼が使用していたサーバーが何であれ、最初の 100K レコードの後、彼を切断しなかったことに、私はかなり驚きました。

彼は 1 秒以内にどんな記録も見ることができました。

于 2009-08-03T17:03:33.727 に答える
2

最後に Access を使用してから数年が経ちましたが、大きなデータベース ファイルは常に、小さなファイルよりも問題が多く、破損しやすい傾向がありました。

データベース ファイルが 1 人のユーザーのみによってアクセスされているか、堅牢なネットワークに保存されている場合を除き、2 GB のデータベース サイズ制限に達する前に問題が発生することがあります。

于 2009-08-03T14:57:15.453 に答える
1

ここでは、必ずしも理論上の制限について話しているわけではありません。2 GB の最大ファイル サイズとデータベース スキーマの実際の制限について話しているのです。

  • あなたのデータベースは単一のテーブルですか、それとも複数ですか?
  • 各テーブルにはいくつの列がありますか?
  • データ型とは何ですか?

スキーマは、保持できる行数を決定する際に行数と対等です。

一部の企業ユーザーによる統計分析のために、MS-SQL データのエクスポートを格納するために Access MDB を使用しています。そのような場合、コア テーブル構造をエクスポートしました。通常は、行あたり 100 バイトから行あたり 8000 バイトまでさまざまな 20 から 150 列の 4 つのテーブルです。このような場合、出荷する MDB ごとに数十万行のデータが許容されます。

したがって、スキーマがないと、この質問に答えがあるとは思いません。

于 2009-08-03T14:47:58.740 に答える
0

Practical ='実際に役立つ'-だから、あなたが得ようとしている最高のものは逸話的です。他のすべては、プロトタイピングとテスト結果です。

私は他の人にも同意します-「レコードの最大数」の決定はスキーマに完全に依存しています-＃テーブル、＃フィールド、＃インデックス。

もう1つの逸話：私は最近、それぞれ36フィールドと85フィールドの2つのプライマリデータストア（テーブル）で1.6GBのファイルサイズに達し、3つの追加テーブルにいくつかのサブセットコピーがあります。

データが一意であるかどうかを誰が気にしますか？コンテキストがそれを示している場合にのみ重要です。重複がインデクサーによる処理に影響を与えない限り、データはデータです。

その1.6GBを構成する合計行数は172万です。

于 2012-05-16T21:44:05.290 に答える
0

それはすべて依存します。理論的には、4 バイトのデータ型の単一の列を使用します。300,000 行を格納できます。しかし、何かを行う前であっても、データベースにはおそらく多くのオーバーヘッドがあります。私はあなたが1.000.000行を持つことができる場所をいくつか読みましたが、それはすべて依存しています..

データベースを相互にリンクすることもできます。ディスクスペースのみに制限します。

于 2009-08-03T09:57:22.537 に答える
0

4 つの大きな Db2 テーブルで作業しているときに、制限を見つけただけでなく、4 つのテーブル (それぞれに 900,000 行を超える) すべてを 1 つの大きなテーブルに追加できると考えた上司に、私は本当に悪い顔をされました。実際の結果は、テーブル (正確に 34 列 - 30 個のテキストと 3 個の整数) を何度試しても、「認識されない形式のデータベースを開けないか、ファイルが破損している可能性があります」という不可解なメッセージを吐き出すというものでした。結論は、1,500,000 未満のレコードであり、34 行で 1,252,000 を少し上回っています。

于 2014-06-08T06:48:39.487 に答える