OKWAVEのAI「あい」が美容・健康の悩みに最適な回答をご提案!
-PR-
解決
済み

MS Access 何となく不安なんですが。。

  • すぐに回答を!
  • 質問No.153774
  • 閲覧数92
  • ありがとう数3
  • 気になる数0
  • 回答数2
  • コメント数0

お礼率 75% (40/53)

またしても変な質問なんですが、皆さんの意見をお聞きしたいです。

アクセスを弄り始めて一ヶ月半程ですが、色んな壁にぶかりながら何とか自分のやりたい様な形に出来そうな目処がつきました。
。。。が、自分が作ったこのDBで何度か入力テストを行いテスト結果は上手くいってますが、この先レコード数がどんどん増えていった時に、どこかで破綻しないか心配です。
っと言うのも、幾つかのテーブルで主キーが複数ついており、例えば通常ですと見積テーブル中の見積CDフィールド単体(主テーブル)と明細テーブル中の見積CD(リレーションテーブル)にリレーションを設定し(逆に設定しても)一対多となるのは合点が行くのですが、見積テーブル中の見積CDと仮番CDを複数で選択し明細テーブル中の見積CDと仮番CDに関連付けないと一対多にならない(主テーブルになりえるテーブルが限定されてしまっている)と言うのが、どうも無理やりなやり方ではないのか、また無理なやり方な為にレコード数が何百何千と増えた時に、システムの破綻が起こらないか心配です。
各テーブルの中で複数の主キーが重なり合ったこの様な状態ですと主キー、リレーションなどへの理解の浅さが自分でも認められるだけに『上手くはいっているけど本当にこれでいいのか?!』っと言う不安が尽きません。。

色々と難解な文章で長々書いてしまいましたが、とどのつまり、色々なテストを数回行い上手くいくと言う事は、レコード数がいくら多くなっても大丈夫だと自信を持ってもいいのでしょうか?

どうせ駄目になるなら今のうちに直しておきたいし、単にDBが駄目になるだけでなく、それまでのデータも駄目になってしまうことを考え、率直なご意見をお聞きしたいです!
変な質問だと思いますが、何卒宜しくお願いします。m(__)m
通報する
  • 回答数2
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

質問者が選んだベストアンサー

  • 回答No.1
レベル13

ベストアンサー率 26% (267/1014)

>レコード数がいくら多くなっても大丈夫だと自信を持ってもいいのでしょうか?
 多くなるというのは、
>何百何千と増えた時
 のことでしょうね。

 自分(または自分がそばにいる環境)で使って行くなら、適宜改良して行く事で、利用しつづける事は可能でしょうが、シェアウェアとか業務ソフトなど他人が使用するならテストすべきです。(ここで質問してるってことは後者ではないと思いますが・・・)

 自分で利用する範囲なら、「だ~いじょうぶ」です。

テーブル破壊さえなければ、数千レコードくらいは、手修正可能ですよ。

 ただし、自営業か何かで帳簿を載せようとしておられるなら、要注意。毎日mdb以外のファイルにエクスポートしてバックアップしましょう。

 データベース一般に言える事で、レコード数の限界は、意外と少ないです。一概に「何件でこうなる」とは言えませんが、パソコンでは単純なレコード検索でも数万件で、テストとは違った応答時間、連続使用限界になると見ておいたほうがいいです。パソコンRDBでは、もっと少ない件数で限界が来ると思います。

>主キー、リレーション
 の部分は、読み飛ばしてしまいましたが、(スイマセン)何をどうしようが、テーブル破壊だけなければ、少々ヒモ付けできてないレコードが残ろうが、大丈夫。(最後は手修正)
(オペミスでマスタ、バックアップをDELETEしたなんてのは、論外です)

ちなみに、私は、Accessは、信用していないので、テーブルに主キー、リレーションを設定しません。リレーションは、レコード番号を管理して、実現しています。これが、マスタテーブルを保護する最善の方法だからです。
これなら、プログラミングは手間を食いますが、CPU486,128MB,Win95+NTのファイルサーバーで、20万件程度で稼働しているものもあります。
補足コメント
whitemark

お礼率 75% (40/53)

それと書き忘れてしまいましたが、実務でメインで使うのが社長で、この社長がまた「ダブルクリックって何?」というレベルですので、余計に心配しているわけです。。。
出るのはため息ばかりです。。(汗
投稿日時 - 2001-10-19 11:13:10
お礼コメント
whitemark

お礼率 75% (40/53)

早速のご回答、ありがとうございます!

実はその問題の自営業だったりするわけです。。。
今まで手作業でこなしていた事を、すべてパソコンに置き換える事で、いろんな面のコストダウンを図ろうとしています。ありきたりですが。。
エクセルで名簿を作るのがやっとのレベルでありながら、アクセスなんて無謀だなっとは思うのですが、やらねばならぬ状況になってしまったので。。
会社内のことをしっかり固め、安心して外へ打って出たいのですが、どうも心配性な性格な為、一応目処がついたと言えども、何か落ち着かなくて。。
バックアップはしっかりとる為に、先日記憶装置も買っておきました。
やはりバックアップは大切ですよね。肝に銘じていこうと思います!

それと、なんだかとても読み辛い文章になってしまったことをお詫びします。またこのような文章であるのにご回答を下さって本当にありがとうございました。大感謝しております!
もう少しほかの皆さんのご意見も伺いたいと思うので、締め切らないでこのまま置いておこうと思います。
投稿日時 - 2001-10-19 11:12:28
-PR-
-PR-

その他の回答 (全1件)

  • 回答No.2

 見積テーブルの「見積CD」だけで主キーになっていて明細テーブルが「見積CD」と「行番号(?)」だけで主キーになっていれば、「見積CD」だけで1対多のリレーションになりませんか?「見積CD」がユニークなら、これでも大丈夫なはずです。  数百~数千程度のデータ件数なら、OSのクラッシュ・ディスククラッシュ・LAN環境(HUBの故障)などAccess以外の要因で壊れることは何度か経験しましたが、Access ...続きを読む
 見積テーブルの「見積CD」だけで主キーになっていて明細テーブルが「見積CD」と「行番号(?)」だけで主キーになっていれば、「見積CD」だけで1対多のリレーションになりませんか?「見積CD」がユニークなら、これでも大丈夫なはずです。
 数百~数千程度のデータ件数なら、OSのクラッシュ・ディスククラッシュ・LAN環境(HUBの故障)などAccess以外の要因で壊れることは何度か経験しましたが、Accessの仕様で壊れることはまずないでしょう。またこのくらいの件数だとインデックスなどそれほどシビアにならなくても、パフォーマンスにも大して影響しないかと思われます。
 数万件以上になると、パフォーマンスの面からインデックスなど考慮していやる必要がありますし、いつ壊れても大丈夫なように、こまめにバックアップを取る必要があるでしょう。

 自分の場合、検索に使用する項目には全てインデックスを作成しています。書籍などには「インデックスを多用すると検索は早くなるがレコードの更新に時間がかかるため十分検討して使用するように」みたいにかかれていますが、バッチ処理が多くない限り、全体的なパフォーマンスはよくなるためです。
お礼コメント
whitemark

お礼率 75% (40/53)

ご回答ありがとうございました!
実は明細テーブルの方には「見積CD」「仮番CD」さらに「行番号」があるのです。
何とか減らしたかったのですが、どうしても3段階の番号振りが必要になるんです。。。
やっぱり主キー、リレーションに対しての理解が浅い為、このような事ですぐに混乱してしまうのだと思います。
まったく応用が利かない自分が本当に情けない。。
やっぱりまた大型書店へ行って、主キー関係のことが詳しく書かれている本を探してみようと思います。

ところでアクセスの使用で壊れることはないとの事、とても安心できました。
他業種の仕事に関わった事がないため、数千という数字だけでも膨大な数に感じてしまい、壊してしまったらもう終わりだと感じておりました。
そういえば皆さん何万レコードと言う数をアクセスで振り回しているんですよね。掲示板とうでよく見かけていたのにうっかりしていました。

おふたかたのご回答を頂いて、自信が持てるまでバックアップはこまめに取り、また本を読んで改善策を見つけながら、壊れたら仕方ないと腹をくくりテスト運用してみようと思いました。
他の質問を見ますと、僕のだけものすごーくレベルが低い内容にも関わらず回答して頂いてありがとうございました。がんばりまっす!
投稿日時 - 2001-10-19 19:54:58
このQ&Aで解決しましたか?
関連するQ&A
-PR-
-PR-
このQ&Aにこう思った!同じようなことあった!感想や体験を書こう
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-
-PR-
-PR-

特集


いま みんなが気になるQ&A

関連するQ&A

-PR-

ピックアップ

-PR-
ページ先頭へ