7

人に関する情報 (従業員のプロファイルと関連情報) を含む Access データベースがあります。フロント エンドには、一度に 1 種類のデータを変更する単一のコンソールのようなインターフェイスがあります (あるフォームの学位、別のフォームの連絡先情報など)。現在、複数のバックエンドにリンクされています (データの種類ごとに 1 つと、基本的なプロファイル情報に 1 つ)。すべてのファイルはネットワーク共有上にあり、バックエンドの多くは暗号化されています。

私がこれを行った理由は、MS Access がクエリや更新を行うためにデータベース ファイル全体をローカル コンピューターにプルし、変更されたデータをネットワーク共有に戻す必要があることを理解しているからです。私の理論では、人が電話番号または住所 (連絡先情報) を変更する場合、連絡先情報、プロジェクト、学位、賞を含む単一の大規模データベースを取得するのではなく、連絡先情報データベースを取得/変更/交換するだけでよいというものです。など、1 つの電話番号を変更するだけで済みます。これにより、複数のユーザーがデータにアクセスしているときに、データベースがロックされたりネットワーク トラフィックがロックされる可能性が減少します。

これはまともな結論ですか？私は多くのことを誤解していますか？他に何か不足していますか？

各ファイルのオーバーヘッドの考慮があることは認識していますが、その影響がどれほど大きいかはわかりません。バックエンドを統合すると、そのためのコーディングではなく、カスケード削除などの参照整合性をAccessに処理させることができるという潜在的な利点もあります...

考えや（合理的に有効な）批判をいただければ幸いです。

4

2 に答える 2

9

これはよくある誤解です:

MS Access は、クエリや更新を行うために、データベース ファイル全体をローカル コンピューターにプルする必要があります。

次のクエリを検討してください。

SELECT first_name, last_name
FROM Employees
WHERE EmpID = 27;

EmpID がインデックス化されている場合、データベース エンジンは、一致するテーブル行を見つけるのに十分なだけのインデックスを読み取ってから、一致する行を読み取ります。インデックスに一意の制約が含まれている場合 (たとえば、EmpID が主キーである場合)、読み取りは高速になります。データベース エンジンは、テーブル全体、さらにはインデックス全体を読み取るわけではありません。

EmpID にインデックスがない場合、エンジンは Employees テーブルのフル テーブル スキャンを実行します。つまり、テーブルからすべての行を読み取って、一致する EmpID 値が含まれている行を判別する必要があります。

しかしいずれにせよ、エンジンはデータベース全体を読み取る必要はありません...クライアント、在庫、販売などのテーブル...すべてのデータを読み取る理由はありません。

バックエンド データベース ファイルへの接続にオーバーヘッドがあることは間違いありません。エンジンは、データベースごとにロック ファイルを管理する必要があります。その影響の大きさはわかりません。私だったら、新しいバックエンド データベースを作成し、他のデータベースからテーブルをインポートします。次に、フロントエンドのコピーを作成し、バックエンド テーブルに再リンクします。これにより、パフォーマンスへの影響を直接調べる機会が得られます。

リレーショナル整合性は、テーブルを単一のバックエンドに統合するための強力な議論であるように思えます。

ロックに関しては、日常的な DML (INSERT、UPDATE、DELETE) 操作のためにバックエンド データベース全体をロックする必要はありません。データベース ベース エンジンは、よりきめ細かいロックをサポートします。悲観的ロックと日和見的ロックの比較 --- 行の編集を開始するとロックが発生するか、変更された行を保存するまでロックが延期されるか。

遅いネットワークがワイヤレスネットワークを意味する場合、実際には「遅いネットワーク」が最大の懸念事項になる可能性があります。アクセスは有線 LAN でのみ安全です。

編集: アクセスは WAN ネットワーク環境には適していません。Albert D. Kallal によるこのページを参照してください。

于 2011-04-29T14:51:36.493 に答える