低速ネットワーク上のMS Accessデータベース：バックエンドを分離する方が速いのですか？

Question

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

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

これはまったく結論ですか？私は大したことを誤解していますか？私は何か他のものを逃している？

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

私は、 （合理的に正当な）批判である。

Answer 1

これは一般的な誤解です：

SELECT first_name, last_name 
FROM Employees 
WHERE EmpID = 27; 

：

MS Accessの

このクエリを考えてみましょう任意のクエリや更新を行うために、ローカルコンピュータにデータベースファイル全体を引っ張って持っています

EmpIDが索引付けされている場合、データベースエンジンは十分な索引を読み取って、一致する表の行を検索し、一致する行を読み取ります。インデックスにユニーク制約が含まれている場合（たとえば、EmpIDがプライマリキーの場合）、読み込み速度が向上します。データベースエンジンは、テーブル全体、またはインデックス全体を読み取るわけではありません。

EmpIDのインデックスがないと、エンジンはEmployeesテーブルの全テーブルスキャンを実行します。つまり、EmpID値に一致するものを含むかどうかを判断するには、テーブルからすべての行を読み取る必要があります。

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

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

リレーショナル・インテグリティは、表を単一のバックエンドに統合するための強力な議論になるはずです。

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

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

：WANネットワーク環境ではアクセスが適切ではありません。 Albert D. Kallalによるthis pageを参照してください。