3

シナリオ: 従来のプログラム (どの言語か不明) があり、「データベース内のフォームを圧縮してアーカイブする」ように依頼されました。ユーザーがアプリケーションを開いた時点で、約 27000 レコードをロードするのに約 2 ～ 5 分かかります!!! 私の理論では、起動時にすべてのレコードをロードしているということですが、それだけが理由ではないかもしれません。掘り下げて正しいように見える Access Back end を見つけた後、社内の 15 以上の他の共有でも同じアクセス ファイルを見つけました。このアプリケーションが作成されたのは 1997 年頃で、おそらく Access が標準であったと思いますが、実際には 15 以上の Access データベースからデータを取得するのでしょうか? このプログラムを高速化するための標準のように思われるのは、古いレコードを別のアクセスデータベースにアーカイブすることです (これが、起動時にすべてをロードしていると私が考えている理由です.

質問: 月曜日にプログラムについて話し合う会議があり、役に立つ質問、理論、解決策などを提案してくれる人がいないかと考えていました。これは自分でできないということではありません。別の視点ではできないと思います。傷つく。また、もう 1 つの興味深い事実は、ソース コードが請負業者によって作成され、コードがずっと前に失われた可能性があるため、ソース コードを入手できる場合と入手できない場合があることです。

補足: Access が古い記録を自動アーカイブすることは可能でしょうか? それは、XXXArch という別の DB にそれらを転送することを意味します。

前もって感謝します。ご質問があればお答えいたします。

編集：

近況報告はこちら。

1 つのデータベースのみをメインとして使用し、もう 1 つのデータベースをアーカイブに使用しているようです。アプリケーションを開くための自分のユーザー アカウントはまだ持っていませんが、データベースを調べると、ログイン ID と同じパスワード (PASSWORD) を持つユーザー テーブルがあるため、それらのユーザーの 1 人としてログインして、いくつかのユーザーを選択してみました。何も変更していないデータ。選択すると、ほぼ瞬時にデータを取得でき、他のユーザーが得ていた速度低下は見られませんでした. 私はまだソース コードを見ていませんが、(exe を取得してメモ帳に入れると) わかることから、VBA でコーディングされ、おそらく MS Access を使用して作成されたように見えます。また、アプリケーションがデータ フォルダーに temp.mdb を作成するようです。現在、その中には何もありません。テーブルも何もありません。私' これがユーザーの速度を低下させているものであり、パフォーマンスを向上させるために削除できると仮定/期待しています. ソースコードを入手し、何が遅くなっているのかをよりよく理解したら、別の更新を投稿します.

4

3 に答える 3

5

考慮すべき点がいくつかあります。

Access（MDB）データベースは、頻繁に使用される場合、タイトルに記載されているように、定期的なコンパクト化/修復が必要になる傾向があります。ただし、パフォーマンスが最小限以上に役立つことはめったにありません。非常に長い時間が経過している場合、ファイルが非常に大きく膨らむ可能性があり、ユーザーが低速のネットワーク接続を介してファイルにアクセスしている場合は、それが問題の一部になる可能性があります。

あなたの会社またはこのフォーラムのいずれかで、SQLサーバーのような「より大きな」DBへのアップグレードを提案する人がいます。問題を特定するまで、またはパフォーマンス以外の理由がない限り、これを行わないでください。問題が不十分なアプリケーション設計またはDBアーキテクチャによって引き起こされる可能性は十分にあります。アプローチを変更せずに問題にもっと強力なツールを投げることは、役に立たないでしょう。

Access DBは、データが最大になるずっと前に、同時ユーザーが最大になります。多くのユーザー（30歳以上）がシステムを使い始めたばかりですか？それは問題の一部である可能性があります。

古いレコードのアーカイブ：これを行うには、何かを構築する必要があります。良いニュースは、それがそれほど難しいことではないということです。

15以上のデータベースへのアクセス：フロントエンドGUIがAccessで記述されていないことを確認してください。これは、ネットワーク上の中央のMDBデータファイルに接続するエンドユーザーのマシン（どこにでもコピーされる）にMDBフロントエンドをロードするためのアクセス権を持つ一般的なアーキテクチャです。データベースを開いて、データベースにテーブルだけが含まれているか、テーブル+フォーム/レポートが含まれているかを確認するのが最善の方法です。

于 2010-10-15T13:46:19.780 に答える
4

あなたの最初の仕事は、この問題を解決することだと私には思えます:

ソースコードは請負業者によって作成されたものであり、コードはずっと前に失われた可能性があるため、ソースコードを入手できる場合と入手できない場合があります.

現時点では、実際に何が起こっているのかについての知識がなくても、速度低下の原因と改善策について推測するように私たちに求めています.

于 2010-10-15T14:11:15.093 に答える
3

ソースコードがない場合、バックエンドデータベースをSQLServerなどに変更することはできません。

ただし、実際にデータファイルにアクセスして編集できる場合は、インデックスを確認してみませんか？27Kレコードは、Accessを含むすべてのデータベースにとって些細なことであり、データの読み込みが遅いことは、テーブルが適切にインデックス付けされていないことを示しています。テーブルを調べて、明らかなフィールドにインデックスがない場合は、それらを追加してみて、処理が高速化されるかどうかを確認してください。

そうでない場合は、アプリの設計が不適切であり、ソースコードが不足しているため、それについてできることはあまりありません。

もちろん、上記のすべては、ネットワーク環境がAccess / Jet/ACEに適していることを前提としています。つまり、これらのデータベースファイルが有線LAN以外の方法でアクセスされている場合、それについては何もできません（WANとWiFiはJet / ACEに対して完全に使用されていません）。

最後に、アーカイブに関しては、ハードウェア/ソフトウェアの厳しい制限に実際に直面していない限り、データをアーカイブする理由はないと思います。この場合、あなたはそれにさえ近づいていません。

于 2010-10-16T16:39:16.473 に答える