0

質問のとおりです。テーブルには主キーが定義されていません。データベース内の他のテーブルは、圧縮後に変更されず、主キーも定義されていません。

4

3 に答える 3

2

「テーブルに主キーが存在する場合、コンパクト化により、テーブル レコードが主キーの順序で再格納されます。これにより、非管理クラスター化インデックスと同等の機能が提供され、Microsoft Jet データベース エンジンの先読み機能がはるかに効率的になります。 "

ACC2000: データベースのデフラグとコンパクト化によるパフォーマンスの向上

「新しい圧縮方法。データベースを圧縮すると、インデックスがクラスター化インデックス形式で格納されるようになりました。クラスター化インデックスは次の圧縮まで維持されませんが、パフォーマンスは引き続き向上します。これは、行が行である Microsoft Jet 2.x とは異なります。のデータが入力された方法で保存されました。新しいクラスター化されたキーのコンパクトな方法は、テーブルの主キーに基づいています。入力された新しいデータは時間順になります。

Microsoft Jet バージョン 3.0 の新機能

これらの記事のどちらもあなたに伝えていないことは、観察しなければならないことです:UNIQUE制約 (または一意のインデックス) がNOT NULL列に存在する場合、これは の代わりに使用されますPRIMARY KEY。私が確認できなかったUNIQUEのは、テーブルに複数の制約がある場合に ACE/Jet が 1 つを選択する方法です。最初の列の序数位置? 最初NOT NULLの列の序数位置? あなたの推測は私のものと同じです。

于 2009-06-11T13:40:26.887 に答える
1

テーブルには順序がありません。テーブルのデータシートかもしれませんが、それはテーブルではなく、テーブルを表示するために使用される UI オブジェクトです。

テーブルの順序を制御する場合は、ORDER BY 句を含む SQL ステートメントを使用します。

アプリケーションでテーブル ビューを使用しないでください。

アプリケーションがなく、既定の順序が気に入らない場合は、テーブル データシートで ORDER BY プロパティを設定して保存するか、好みの順序でクエリを記述します。

しかし、テーブルには任意の順序があるという考えを放棄する必要があります。単なるアイデアは、SQL や集合論の基礎と完全に矛盾しています。レコードが実際に物理データベースに格納される順序は気にする必要はありません。

于 2009-06-13T12:48:15.090 に答える
0

主キーがない場合、Access はテーブルの行を自由に再配置できます。私の推測では、効果はテーブルの使用パターンに依存します。行を削除すると、データベースは単純にその行を削除済みとしてマークします。圧縮すると、削除された行を削除されていない行で上書きすることにより、スペースが再利用されます。テーブルに主キーがある場合、データベースはこのプロセス中に行の順序を保持するように注意します (結果として、はるかに高価な操作になります)。そうでなければ、そうはなりません。

于 2009-06-11T13:06:50.400 に答える