質問のとおりです。テーブルには主キーが定義されていません。データベース内の他のテーブルは、圧縮後に変更されず、主キーも定義されていません。
3 に答える
「テーブルに主キーが存在する場合、コンパクト化により、テーブル レコードが主キーの順序で再格納されます。これにより、非管理クラスター化インデックスと同等の機能が提供され、Microsoft Jet データベース エンジンの先読み機能がはるかに効率的になります。 "
ACC2000: データベースのデフラグとコンパクト化によるパフォーマンスの向上
「新しい圧縮方法。データベースを圧縮すると、インデックスがクラスター化インデックス形式で格納されるようになりました。クラスター化インデックスは次の圧縮まで維持されませんが、パフォーマンスは引き続き向上します。これは、行が行である Microsoft Jet 2.x とは異なります。のデータが入力された方法で保存されました。新しいクラスター化されたキーのコンパクトな方法は、テーブルの主キーに基づいています。入力された新しいデータは時間順になります。
これらの記事のどちらもあなたに伝えていないことは、観察しなければならないことです:UNIQUE
制約 (または一意のインデックス) がNOT NULL
列に存在する場合、これは の代わりに使用されますPRIMARY KEY
。私が確認できなかったUNIQUE
のは、テーブルに複数の制約がある場合に ACE/Jet が 1 つを選択する方法です。最初の列の序数位置? 最初NOT NULL
の列の序数位置? あなたの推測は私のものと同じです。
テーブルには順序がありません。テーブルのデータシートかもしれませんが、それはテーブルではなく、テーブルを表示するために使用される UI オブジェクトです。
テーブルの順序を制御する場合は、ORDER BY 句を含む SQL ステートメントを使用します。
アプリケーションでテーブル ビューを使用しないでください。
アプリケーションがなく、既定の順序が気に入らない場合は、テーブル データシートで ORDER BY プロパティを設定して保存するか、好みの順序でクエリを記述します。
しかし、テーブルには任意の順序があるという考えを放棄する必要があります。単なるアイデアは、SQL や集合論の基礎と完全に矛盾しています。レコードが実際に物理データベースに格納される順序は気にする必要はありません。
主キーがない場合、Access はテーブルの行を自由に再配置できます。私の推測では、効果はテーブルの使用パターンに依存します。行を削除すると、データベースは単純にその行を削除済みとしてマークします。圧縮すると、削除された行を削除されていない行で上書きすることにより、スペースが再利用されます。テーブルに主キーがある場合、データベースはこのプロセス中に行の順序を保持するように注意します (結果として、はるかに高価な操作になります)。そうでなければ、そうはなりません。