Accessの処理速度を速めるためにテーブルとそれ以外を分割してもああまり速くならないのですが・・・

質問

Access2003を使用しています。
メンテナンス後保存をしたり、検索をかけたときとても時間がかかるので、データベースからテーブルだけを切り離す方法を試みてみようかと考えています。
テーブルとそれ以外のデータベースオブジェクトを分割する方法です。
試しにコピーをとったファイルで行ってみましたがあまり速度が速まったように感じません。
参考書を読むと、「大量のデータを蓄積するデータベースに威力を発揮する」と書いてあり、見本は300Mバイトになっています。
私がメンテナンスをかけているファイルは65MB程度です。
これぐらいの大きさだと分割する効力は低いのでしょうか？
他の方法を試みたほうがいいのでしょうか？
ちなみにCPUはあまり高くありません。
どなたかこの方面にお詳しい方がいらっしゃいましたらご教示ください。
よろしくお願いいたします。

回答No.8

noname#60992 · ベストアンサー

>MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。
「なっているため」という言葉遣いは正しくなかったかもしれません。
「なるのかもしれないので」位の意味でした。　申し訳ありません。

No6の回答は憶測で書いています。（何の根拠もありません。）
コンピュータやプログラミングの専門家でもありませんし、
私のアクセスの経験もかわいいものですので、（97から）
「こう考える素人がいる」というくらいにとってください。

ちょっと考えてみましたが、ｍｄｂのデータファイルの構造は以下のようになっているそうで、
http://www.mrdb.ne.jp/technic/se_guide/d_fkouzo.htm
最適化を行うと
・データ部分のブロックが減る
・インデックスによる順番付けがなされる
ので検索に対するパフォーマンスがあがるということには異論はないと思います。

問題はフォームやレポートをいかに保存しているかですが、
やはり決まった単位のブロックを用意して、オブジェクトを書き連ねているのかなと思います。　
（前言を撤回することになりますが）そうだとすると、データ部分を切り離すことと
フォームのサイズを小さくすることは関連性がないということになり、
フォームをセーブするときの時間も、データを切り離したところでフォームを最適化しないと、
あまり変わらないということにもなりそうです。
データ部分のみが最適化されたｍｄｂと、すべてのオブジェクトが
最適化されたものの保存時間を比べてみればヒントはつかめそうですが、、、
そのような実験にあまり意義を感じません。（そこまでアクセスを愛していません。）　

いろんなＤＢがありますが利用する際は定期的に最適化を行わないといけないのではないかと思います。
アクセスも例外ではないということです。

>テーブルは必ず別mdbにして、「閉じるときに最適化」していますので
これを行っていれば、保存に関してこれ以上の効率化は難しいと思います。（コーディングを変えない限り）
逆にこの状況で何らかの問題があるなら、
・データ構造は適正か？
・データにどうアクセスするか？
・コードをどう記述するか？
・ハードウエア（通信環境含む）は適正か？
これと共に、
・ＤＢは適正か？
を診断しなくてはいけないと思います。

質問者さんに対してのアドバイスは、
・実運用中のものを開発する際は、別ファイル（コピー）を作りそちらに手を加える。（実データで開発を行うことは望ましくないと思う。）
・手を加えたものをリリースする前に最適化をする。
・実運用中のものには定期的（期間はｄｂの更新頻度やつくりにもよる）に最適化を行う。
・データに関しては、何らかの形で定期的にバックアップをとる。
以上のような行為が必要で、
それを怠ると、いつかきっと痛い目にあう（かもしれません。）
データとその他の部分を切り離すと、
・データファイルが破損する可能性が低くなる。
・上記のようなメンテナンスが行いやすくなる。
・他のｄｂへの移行がやりやすくなる。
というメリットがあります。

回答No.7

ogohnohito

No.5です。
この場をお借りして、No.6さんにお尋ねします。
----------
>>フォームのデザインを変えた時に保存をかけると30秒....
>MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。
----------
　とすれば、データが増えると、チョッとした修正であれば、保存の方が時間が掛かることになりますねェ‥‥
私は、テーブルは必ず別mdbにして、「閉じるときに最適化」していますので、そういう経験はない‥‥と言うことになりますかぁ～

回答No.6

noname#60992

No1です。

データを分割させることについての必要性については、皆様がおっしゃっておられるとおりです。（必須です）
>フォームのデザインを変えた時に保存をかけると30秒....
（実験していないので、ただの憶測ですが）MDBファイル自体が小さくなるので、データを分割すると早くなる可能性はあります。
MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。
>新規レコードを追加したときはそれほどでもありません。
これまた憶測ですが、追加の際にはファイルの末尾にデータを加えている（appendしている）だけなので速いのかもしれません。

回答No.5

ogohnohito

No.2のogohnohitoです。
　No.4さんはAccess1.aから使っていたのですね。私はその頃「桐」を使っていたはずです。桐の「大遅刻」でAccess2.0に移行しましたぁ～

　質問者さんは、
> 分割させる方法は意味がないようなのでやめることにしました
と言っておられますが、決してそんなことはありません。むしろ「分割すべき」です。
　私は「中間テーブル」を使う方（たぶん）なので、データテーブルと中間テーブルは必ずmdbを分けています。結果として３っのmdbで一つのシステムになります。その目的は、No.4さんの云う「保守性、拡張性」です。
息の長いシステムにするには「分割すべき」です。

回答No.4

nda23

Accessで、アプリケーション・システムを構築する場合は分割するのが当然と考えます。
Access1.a～Access2000頃まで10年近く、Accessでシステムを構築してきましたが、
分割してある方が、保守性、拡張性が高いと言えます。非分割型に比べると、
最初にテーブルを開く時に遅いことが欠点ですが、２回目以降はファイルが
開いているので、処理速度の劣化はありません。但し、非分割型より速いかと言うと、
目覚しい向上は期待できません。
尚、DBを最適化すると、処理速度が向上しますが、分割している場合はVBAで処理可能です。
http://www.geocities.jp/cbc_vbnet/kisuhen/mesodo.html

回答No.3

kurodai2

その本で書かれているのが、「速度が速くなる」目的なのか判断しかねますが、単純に分けたからといって早くなることは無いと思います。
が、ネットワーク環境でファイル共有にしている場合は、分けることによってネットワーク トラフィックを少なくできるので　その意味では早くなります。
複数ユーザーで利用する場合には、データのMDBだけを共有するのが（リンクテーブル）いいですね。
あとは、１ファイルで処理しているより　ファイルが壊れた時のトラブルを回避できる点や、開発中でも完全に分離していると　テンスと環境等も作成しやすい面があります。

回答No.2

ogohnohito

No.1さんの言うとおりで、「テーブルの最適化」と「適正なインデックス」に懸かっていると思います。
更に、テーブル以外のmdbを（閉じる時に）最適化したりmde化すると、体感はありませんが速くなる方向にあります。

回答No.1

noname#60992

専門家ではないので、はずしているかもしれませんが、
>テーブルとそれ以外のデータベースオブジェクトを分割する方法
これによって、パフォーマンスが大きく変わるとは思えません。
（大きなアクセスファイルを使う上では必須の行為だと思いますが）
検索の速度はどのようなテーブル（フィールド数、レコード数）から、
どういう形で（どのフィールドに対して、どういう形の）検索を行っているのかによります。
抽出の速度を上げるためには(1)テーブルの最適化と(2)適正なインデックスの作成がメインだと思います。
それを行ったうえでのパフォーマンスに不満があるなら、
検索方法の見直し、テーブル構造の見直しやDBMSの変更を視野に入れるべきだと思います。
保存に時間がかかるというのは、意味がはっきりとわからないのですが、
何らかの形でバックアップなどを取るときに遅いということでしょうか？　
それとも、レコードを挿入するのに時間がかかるということでしょうか？
レコード挿入についてでしたら、これまたどのような形でレコードを挿入されているかにかかってきます。

補足

補足ですが、保存に時間がかかるというのは、フォームのデザインを変えた時に保存をかけると30秒ほどかかります。
新規レコードを追加したときはそれほどでもありません。意外と早いです。
これはどうしてなのでしょうか？
よろしかったら教えていただけないでしょうか。

なお、分割させる方法は意味がないようなのでやめることにしました。
教えていただいたテーブルの最適化と適正なインデックスの作成を見直してみようと思います。