| 過去の桐井戸端ＢＢＳ （桐ver.８） |
| 29086 | 共有更新で開く表を使った一括処理システムを速くするにはどうしたらよいのでしょうか | やっつけシステムエンジニア | 2005/02/17-15:50 |
|
現在、ver.8.7を使用しております。 一括処理で、他の3つ表を参照する為に、共有参照先に開かせております。 (下記の様) A.tbl, モード=共有参照 B.tbl, モード=共有参照 C.tbl, モード=共有参照 D.tbl, モード=共有更新 D.wfm 数人(2-3人)が一緒に使用しますと、一括処理がとても遅くなってしまいます。 何か良い方法は無いのでしょうか？ 当然、A-C.tblをローカルにコピーし、それを参照すれば早くなると思いますが・・・ (そうすると、リアルタイムでの更新が出来なくなり、ちょっと困ります。) 何か良いアイデアがあれば、教えて頂けると幸いです。 | |||
| 29087 | Re:システムを早くするための | 宮城 | 2005/02/17-16:32 |
| 記事番号29086へのコメント やっつけシステムエンジニアさん、こんにちは。 V8では、A-C.tblは明示的に開かないほうがよいと思っていますがどうでしょうか。 | |||
| 29088 | Re:システムを早くするための | 尾形 | 2005/02/17-16:41 |
| 記事番号29086へのコメント どうも、こんにちは >D.tbl, モード=共有更新 最大のネックはここの「共有更新」と思いますが 違ったらすいません | |||
| 29091 | Re:システムを早くするための | やっつけシステムエンジニア | 2005/02/17-17:46 |
| 記事番号29087へのコメント versionを上げると、解決出来ると思いますか？ Dの共有更新は、どうしても必要のため、はずせないのです。 ヤッツケシステムエンジニア | |||
| 29095 | Re:システムを早くするための | 野良犬 | 2005/02/17-21:03 |
| 記事番号29086へのコメント 最新のバージョンは試したことはないですが、基本的に桐８と９では大きな速度差はないように思います。 とりあえず、一番確実なのはハードウエアのスペックを上げること、ネットワークをギガビットにすること、でしょうか。 今現在、クライアントの性能が低い(Pen500Mhz 128MB-RAM 程度)のなら、 ハードウエアの増強はかなりの効果が期待できます。 ネットワークを増強するのも効果的です。 どっちにしても、データ件数が多く、同時に複数のPCで更新する用途には桐は向かないことは間違い有りません。 | |||
| 29104 | Re:システムを早くするための | MIT | 2005/02/18-17:54 |
| 記事番号29086へのコメント やっつけシステムエンジニアさん 桐のようにファイル共有するタイプのデータベースシステムでは 共有更新クライアントが２台目になった時点でレスポンスの低下が 顕著となり、以降台数に応じて低下傾向が増加していくと思います。 過去に何度か投函させて頂いた内容ですが、対応策として 更新の可能性でテーブルを分ける。 例えばD.tblにあるデータで更新の可能性が低い過去データがあるとすれば、 それはD_OLD.tblなどに分け、これの閲覧は参照で 別フォームとします。そして何らかのタイミングでDからD_OLDへデータ移動を行う一括処理を作成します。 要するに共有更新する表の行数を少しでも減らす事です。 入力する可能性が低い項目は別の表に分ける。 例えば「メモ欄」など入力されない事の方が多い項目があれば 別表として共有更新する表１つ１つの容量を小さくします。 索引の有無がレスポンスに大きく影響するフォームは使わない。 グループ項目があるフォーム、サブフォームを含むフォームなどが これに該当すると思います。 共有更新する表に索引を作らない。 共有では索引が機能しません。よって表の容量を少しでも小さくする 為に索引は無い方が良いと思います。 データ構造を工夫する。 数字型データで間に合うものは数字で表現します。これも表の容量を小さくする為です。 野良犬さんが述べられている通り、クライアントやネッットワークの ハードウェアスペックを可能な限りあげる事も効果が期待出来ます。 反対にサーバー側は搭載するハードディスク及びＬＡＮボードの性能など が影響すると思いますが、高速なCPUを搭載したサーバーを導入しても 高いコストパフォーマンスは期待しない方が良いと思います。 以上、今さらの話ばかりですがご参考まで。MIT | |||