4

会社のサーバー上のアクセス データベースに対して記述された Windows MFC アプリがあります。データベースはそれほど大きくありません: 19 MB。一度にアクセスするユーザーは最大で 2 ～ 3 人です。これは、ウィジェットの製造時間の一部であるため、イントラネット経由のアクセス速度 (または速度不足) が顕著になる工場環境で使用されます。

シナリオは次のとおりです。各ウィジェットが完了すると、データベースにレコードが取得されます。年末までに、データベースは大きくなり、レコードの検索に時間がかかります。これまでの解決策は、年に 1 回、古いレコードをアーカイブ テーブルに手動で移動することでした。

現在、このアプリの他の部分を作り直しています。それを行う場合は、別のデータベースに移動するのが良い時期です。

SQL を使用している場合、.mdb 全体を毎回ネットワーク経由で送信する必要がないため、テーブルが大きくなっても検索時間が長くならないことを理解しています。これは正しいです？新しいデータベースに移行するという手間 (時間とお金) を費やす価値があるかどうか、または現在使用しているアプリケーションに機能を追加して、古いレコードを自動的に消去する必要があるかどうかについて、誰かが洞察を持っていますか?必要に応じて古いレコードにアクセスできるように、アプリに機能を追加しますか?

共有できる知恵をありがとう..

4

6 に答える 6

4

あなたのデータベースは小さく、ユーザーも非常に少ないため、移行の確固たる根拠を示すことができませんでした。古いレコードをより頻繁にアーカイブするスクリプトを明確に設定します（同じデータベースにアーカイブしないでください。これにより、目的が多少損なわれます）。ただし、2 つの点が正しいことも確認してください。

  1. インデックス。クエリの速度が低下し始めた場合は、適切なインデックスがあることを確認して ください http://support.microsoft.com/kb/304272
  2. コンピュータ間のネットワーク接続は高速です。おそらくギガビットカードとルーターにアップグレードしますか？場合によっては、データベースを SCSI ドライブに配置します (速度と冗長性のために RAID 10)。

単純な問題に高度な技術を投入するのは費用がかかり、必ずしも答えとは限りません!

于 2010-05-04T21:38:22.010 に答える
4

まず第一に、テーブル全体とデータベース全体がネットワークを介して転送されるという情報は、まったく正しくありません。クエリがインデックス化されている場合、検索時間は時間の経過とともにそれほど増加することはありません。

他の人が言及しているように、セットアップと維持に時間とお金を費やしてから、誰かにデータベースサーバーの維持と管理とサポートを依頼することは確かに可能です。ただし、多くの場合、JET ベースのアプリケーションを単純に SQL Server に移行すると実行が遅くなることに注意してください。実際、ネットワークが関与していない場合、SQL Server は JET よりも遅くなります。

そのため、時間がかかる理由を確認し、インデックス作成がどのようにセットアップされているかを確認します。

そのため、テーブル全体とデータベース全体がネットワーク経由で転送されるというのは、単なる伝承と神話であることを覚えておいてください。この概念は、ほとんどの人がコンピューターのトレーニングを受けておらず、JET データ エンジンがどのように機能するかを知らず、理解していないためです。

于 2010-05-05T02:50:37.363 に答える
3

資金とデータ アクセス層を配置する時間の両方があれば、Microsoft SQL Server 2008 R2 Express Edition (無料) または MySQL (無料) に移行するでしょう。リモート サーバーのリクエストを作成し、ローカル ワークステーションでデータを操作しないため、この移動は開発の観点から非常に複雑です。

ただし、アーカイブ プロセスを四半期ごとまたは毎月実行する方が費用対効果が高いかどうかを分析し、アーカイブ データベースを SQL Server 2008 R2 Express Edition に移動するだけです。(Microsoft SQL Server Management Studio クライアント ツールをワークステーションにインストールし、アーカイブ データベースにクエリを実行して、本番アプリケーション全体を書き直すことなく、履歴データに関するより高速なレポートを取得できます。MySQL やその他の OSS/フリー RDBMS を使用するための同様のソリューションが存在します)。

于 2010-05-04T21:13:38.157 に答える
3

他の理由で SQL Server にアップサイジングする必要がありますが、300 MB のデータベースを使用するクライアントがあります。19 Mb は比較的小さいです。パフォーマンスが悪いためにアーカイブがスピードアップする場合は、すべてのソートおよび選択フィールドのテーブルへのインデックスを確認してください。Albert は、チェックするのに適した URL を教えてくれました。

MDB ファイル全体が送信されるわけではありません。インデックスがない場合を除きます。

于 2010-05-05T06:30:54.653 に答える
2

DB をネットワーク経由でクライアントに送り、クエリを実行する代わりに、要求を処理し、(SQL + Access ODBC ドライバーを使用して) Access DB で結果を検索し、返す小さなラッパーをサーバー上に記述することができます。結果。これにより、必要のない大規模な移行のオーバーヘッドが回避され、ユーザーが経験している基本的な問題が解消されます。

「適切な」データベース ソリューションへの移行は長期的には最善のソリューションですが、今後 30 年間でニーズが直線的かつゆっくりと拡大する場合、費用のかかる移行を正当化することは困難です。とはいえ、本当に強化することを期待している場合、またはより「将来性」を高めたい場合は、今すぐ移行することでおそらくお金と時間を節約できます.

于 2010-05-04T21:16:44.357 に答える
0

SQL を使用している場合、.mdb 全体を毎回ネットワーク経由で送信する必要がないため、テーブルが大きくなっても検索時間が長くならないことを理解しています。これは正しいです？

この一般的な考え方は、ほとんどすべてのデータベースに当てはまります。データベースの考え方は、アプリケーションを実際のデータから分離することです。データはデータベース サーバーに存在します。あなたのアプリケーションはそうではありません。

新しいデータベースに移行するという手間（時間とお金）を費やす価値があるかどうかについて、誰かが洞察を持っていますか

はい。これを何度も提案しました。高いです。それは複雑です。MS-Access データベースが改善されたり高速になったりすることはありません。

他のデータベース サーバーは、より高速で洗練されたものになるでしょう (そしてそうなる可能性があります)。結局のところ、ネットワーク経由で .MDB ファイルを送信することはもうありません。制限が軽減されます。ODBC を介して標準 SQL を使用しています。どのデータベースも ODBC の最後で機能します。ベンダーを解雇して、より優れた、より速く、より安価な製品を見つけることができます。Access の使用を停止すると、選択肢があります。

Access の使用を今すぐ中止するか、永遠に使い続けることを計画してください。そして、この決定は毎年終わりまでやり直してください。

于 2010-05-04T21:13:29.057 に答える