| |
▼わん さん：
こんにちは。
>>レコード数が増えると、使用されている環境によりますがAccessの動作が遅くなります。
>>5万件位のレコードで速度に問題があるようでしたら(クエリの表示、抽出など)
>>テーブルの設計等を少し考え直す必要があるかもしれません。
>
>過去ログを読むとかなりのデータ量でも耐えられるような気がしますが。
一般的に言われていることですが、文字列操作(Left、Instrなど)を使ったり
クエリからクエリを呼び出したりすると動作が重くなるそうです。
また以前他の方の回答であったのですが
検索の際にレコードが多いと画面が固まってしまう事があったそうです。
(レコード件数はどれくらいか解りませんが)
何件を超えると…というデータがある訳ではないので、
現在のところ推定これだけは使いそうだ、×1.2くらいのレコード数で
一応実験しておいた方が無難かもしれません。
給与計算のところで Iif をクエリで使いましたが、
本当はあれもあまり良くないですね…。
>私としては、データを年度末若しくは月末に清算できるような
>マクロ記述により別テーブルを作成するようなことができればいいと
>考えているのですが難しいのでしょうか？
>それとも、基本のテーブル設計をより良いものに考え直す方がいいのでしょうか？
月ごとのテーブルを持たせるメリットとデメリットがはっきりしていれば
そう難しくない話だと思います。
メリット ：扱うデータ量が少ないので処理が軽い！
デメリット：1) 月をまたぐ処理(15日から翌月15日までとか…)の処理に手間がかかる。
2) テーブル数が多くなるので必然的にmdbの容量が増える。
3) テーブル名を直接記述できない。
当方が使っているmdbですと、
・過去月のデータを見るのは1年に数回
・前年以前のデータはまず見ない
事から、
・mdbは年度単位
・テーブルは「今月テーブル」「先月以前テーブル」(もちろん名前は違いますが)
として、
・今月の処理(参照、更新)は速い
・先月以前の参照は呼び出すのに3秒くらい時間がかかる場合がある
・前年以前はその年のmdbを開き直せ
という感じですね。
|
|
小僧
- 05/8/17(水) 18:19 -
