テーブルとフォーム等の分割について

質問

現在、3種類のテーブルを用意しています。

１）データ格納用テーブル（メインテーブル。情報の追加登録・修正用として）
２）基幹システムのDBとリンクしているテーブル（クエリを使用してのリアルタイム検索用として）
３）追加修正が発生しない固定的な情報を持つテーブル

ある情報によるとメインDBとクエリやフォーム（アプリケーション？）とは分けて保存、
使用した方が良いという事を聞きました。

これを意識して１）のメインテーブルは独立させ、２）と３）はアプリケーションのテーブルとし、
アプリケーション側からメインテーブルにリンク設定しクエリやフォームを作成しています。
その際、メインテーブル側に持たせるべきテーブルとはどの様なものなのか判断が付きません。
もしかしたら２）も３）もメインテーブル側に持たせ、アプリケーション側のテーブルは全て
リンクを張るべきなのでしょうか？

テーブルとフォームの分割とは、この様な考え方で宜しいのでしょうか？
こうする最大の目的はマルチアクセスの環境を作る事なのですが・・・・
また、AccessはSQLサーバーやＯｒａｃｌｅ等堅牢なDBではないため、
マルチアクセス環境には向いていないとの話も聞きますが、この点についても
教えて頂ければと思っております。

宜しくお願い致します。

回答No.1

hatena1989 · ベストアンサー

> もしかしたら２）も３）もメインテーブル側に持たせ、アプリケーション側のテーブルは全て
> リンクを張るべきなのでしょうか？

２）、３）のテーブルが固定的なもので頻繁に更新されない、または更新されてもリアルタイムに反映しなくてもいいというものなら、アプリケーション側（一般的にはフロントエンドといいます）に置くという設計もあります。
メインテーブル側（一般的には、バックエンドといいます）にすべてのテーブルを置くという設計もあります。

パックエンドにマスターテーブル（固定的なテーブル）を置く設計の場合、マスターには頻繁にデータ読み込みが発生しますので、ネットワークトラフィックが多くなり重くなる可能性があります。
フロントエンドに置けば、ネットワークを経由する必用がないので、処理が軽くなります。
ただし、各クライアントに分散して置かれることになるので、もし、更新があった場合、すべてのクランアントに反映させる処理が必用になります。

> また、AccessはSQLサーバーやＯｒａｃｌｅ等堅牢なDBではないため、
> マルチアクセス環境には向いていないとの話も聞きますが、

堅牢性はSQLサーバーやＯｒａｃｌｅと比べればそりゃー比較になりません。
コストが一桁、二桁違いますから当然と言えば当然です。

ネットワーク環境や入力状況にもよりますが、
同時アクセスが、参照のみなら、20人ぐらいまで、入力更新なら10人以下、できれば5人ぐらいまで、
なら、そこそこ実用にはなると思います。
もちろん定期的なバックアップをとるような運用は必須です。
幸いMDBファイルは、バックアップソフトで簡単に自動でバックアップできます。

お礼

お礼がおそくなりまして申し訳ございません。
非常に参考になりました。まだ分割作業は行っておりませんが
参考にしながらやってみたいと思っています。
ありがとうございました。