Beginner検索Q.Accessって1万件超えると遅くて使い物にならないって本当ですか?本当とも言えますし、嘘だとも言えますね。Accessに限らず、現在のPC上で動作するアプリケーションのすべてにおいて、一定のパフォーマンスを保証することは不可能です。動作するハードウェア、ソフトウェア環境によって大きく違ってしまうため、ソフトウェア実行においてのベンチマークになんの意味もないからです。「あるマシンで1時間かかった処理が違う環境では1秒かからない」ことも当然ありえる、いえありえるどころじゃない、現実としてあるのです。「マイク○ソフトはベンチマーク結果を公表しないんですかっ!?」としたり顔で(実際は電話ですから顔は見えないんですけど)文句言ってくる人もいましたが、こんなこと言ってる人は素人ですから言うことをきいては駄目です。PCというのは、ハードウェア環境がすべて一定に保証されている汎用機と違って、自作マシンもあればメーカー機もあり、AT互換機もあればPC98マシンもありと、ハードウェアの性能が一定じゃないんですから、処理時間なんて計ったって完全一致する環境があるワケがないんです。そんな信用できない情報を欲しがる人の気が知れません。「じゃあ、一般的な環境でいいから・・・」一般的ってなんですか??一般的って??余計わかりませんよね。マシン購入時には「標準スペック」とか気軽にいいますけど、これも「買う人の予算範囲内で納得できるスペック」って意味ですからぜんぜんアテにはなりませんよね。自分のまわりの人(会社の人?)が使っている環境=世間の標準と思ってるなんて、なんて幸せな人なんでしょう。言われる「ベンチマークソフト」、あれはハードウェアの性能を計るためのもので、ソフトウェアのレスポンステストとは必ずしも一致しません。優れていても、HDDの読み込み・書き込みが遅ければやりたいことによっては遅くなることだってありますし。すべての環境において保証できないベンチマークなど公表して何になるというのでしょう。「参考までに」聞いたところでどうしようというのですか。他の人のシステムも遅いと確認して安心したいのでしょうか。原因を追求することもせず、遅いのを全部Accessのせいにして「Accessなんて使い物にならねぇぜ!」と堂々と言う奴には、「使えねぇのはおまえだよ」と、言ってやりましょう。(^^;)それは値段にもハッキリ現れていますよね。ベンチマークを公表してるみたいですが、製造元が出したベンチマークなんて信じちゃ駄目です。どんな都合のいい環境でどんな都合のいいデータを出したのかわかんないんですから。他社製品と比較してたって、自社の環境での結果なんですから、いわゆる「広告用当社比」だと思っていいと思います。短いから導入費用は安くてすむし、バックアップさえしっかりとれば運用もラクだし、Accessならではのメリットもたくさんあるのです。カネをかけりゃぁレスポンスアップできて当たり前です。安くて質の良い物を提供するのが技術者の心意気ってもんじゃぁないですか?!と、いう訳で。レスポンスアップしたい場合に、チェックするポイントは以下のとおりです。なにをしている部分に一番時間がかかっているのかまず原因を突き止めることです。「決まってるじゃん、検索だよ検索」としか言わない上司、アナタ検索って意味わかってますか?Accessでの検索処理のやりかたには無限に方法があります。1件づつ判定して他テーブルに抽出している場合、複数のクエリーを実行して絞り込みを行っている場合。複数フェーズで実行している場合には各フェーズでしっかり時間を計測しましょう。3つのクエリーを実行していて、2つめだけが異常に遅いといった場合、そのクエリーの条件式を見直すだけで処理時間は100分の1、1000分の1にもなりえます。使っている場合、マイクロソフトのサポート情報にバッチ処理時のレスポンスアップのコツを記述した資料がありますので参考にしてください。インデックスは適切かどうか1万件でも10万件でも、適切なインデックスがはられていて適切なデータ量単位で検索して使えばそれほど遅さは感じません。10万件から1件検索するのも、1件から1件検索するのも、インデックスを使用して検索する場合には速度の違いを体感することはほとんどないんです。データ量が増えて遅くなった場合、テーブル構造とインデックスに問題があります。検索に使用したり、他テーブルとの結合に使用する項目には「重複あり」でもいいですからインデックスをつけるようにしましょう。むやみにインデックスをつければいいってものでもありません。インデックスが多ければ更新に時間がかかるので必要最小限のインデックスを効果的に使うようにしましょう。適切なインデックス構築は、データベースソフトにおいて設計者のセンスと腕のみせどころです。スワップしていないかどうかたぶん、1万件だの3万件だのを超えると突然遅くなるって言う人たちの場合、そこがスワップするかしないかの境目なのではないかと想像しています。いう人はレスポンスチェックなんてやったことがない素人です)スワップが起きるのと起きないのでは処理時間が雲泥の差です。見直せるものならハードウェア構成を見直す、余計な常駐アプリケーションを終了するなどしてみましょう。言っても、通常はハード構成なんて変更できないですよね。いう場合は、1度に処理する件数をフォームやレポートの仕様で制限してしまうのです。だいたい1画面に100件だの1000件だののレコードを一度に表示したって、たいがいの場合は該当レコードを探すだけでイヤになってしまいます。適切な検索条件を入力させて、画面に表示する前にデータを絞り込んでしまえばだいぶストレスを感じなくなります。頻繁におこるイベントで余計な処理を実行していないかフォーム上でカーソルが動くのが遅い!とイライラする場合、フォーカス喪失時やフォーカス取得時、レコード移動時などに指定している処理がいちいち動いてしまって余計な負荷をかけている場合もあります。コンボボックスの再クエリー。これはコンボボックスがフォーカス取得するたびにやっていたら、条件が複雑で処理時間がかかるクエリーの場合などはさすがに気になります。いう処理はコンボボックスの絞込条件が変わらなければ再クエリーする必要はないんですから、絞込条件になるテキストボックスの更新後処理などでやるようにしましょう。最適なイベントで最適な処理をすることもレスポンスアップの重要なカギです。ネットワークのレスポンスネットワークが遅い場合。サーバーにMDBを置いて共有アクセスしていれば、当然ネットワーク負荷の影響をもろにかぶります。RASでログインしていて「Accessだから遅い」なんていわれちゃAccessも浮かばれません。こんなとき遅いのをAccessのせいにしてはいけません。このままのネットワーク環境でOracleに乗せかえる、なんて話がでてきちゃったらどうします?開発費用だけがかさんでレスポンスは全然あがらないってことになったら、信用問題どころが訴訟が起こりますよ。経由で、某汎用機のデータベースの中身を参照し画面に一覧表示するというプログラムをAccessで作ったことがあります。相手は汎用機、データは4万件以上あり、さらにインデックスがはられていない!!いや単にODBCで利用できるインデックスが無かっただけかもしんないですけどこんな状態なので、リンクテーブルをただ開くだけで、最初の文字が出るまでに約15秒かかっていました。ナンジャソレといわれて、試行錯誤を繰り返した結果、次のようなことがわかりました。「or」条件をつけると遅いのです。絞り込むため結果レコード数は少なくなるのですが、10件該当したとしても40秒以上かかっていました。ところが「or」がつかない条件だと、結果は4万件あっても15秒程度で終わるのです。ドライバはお手上げするらしく、or条件以外の式を評価した結果のレコードセットをいったん作成し、Fetchして再度絞り込みを行っていました。ワークテーブルに落とし込みました。データを複写しちゃったんですな。そのあとor条件にあたる条件式で再度絞り込みを行い、再抽出するようにした結果、2度目の抽出は時間計測不可能な処理時間(つまり、1秒未満)で終わるため、どんな条件式を設定しても15秒で画面を表示できるようになりました。普通であれば2度手間抽出したほうが速いなんてことは想像もしないでしょう。終わらせるのが良いとされていますし。この例に限らず、「or条件式」が入る抽出は一般的に遅いです。同じ結果レコードセットなら、条件式が少ない方が処理時間は圧倒的に短くてすみます。A_Masterというクエリーでは、たとえ結果が一緒でも処理速度は全然下の方が早いですから、isnull(forms![MyForm]![KeyCode])がTrueの状態のときには条件式をつけずに検索するのが一番速いのです。文を構築して実行するぐらいのことはしなくてはダメだと言えるでしょう。遅い原因を追求し明確にさえしてしまえば、このような手段をとることはそれほど難しくはないのです。レスポンスアップはケースバイケース、経験がモノを言う匠の世界です。基本原理編これマジデお勧め。検索エンジン経由でこの記事にたどりついた人はぜひ読むべき。高いけど金でこれだけの内容が手に入れば安いもんだ。