ネットワークサーバー上で多人数入力を前提としたAccessの環境構築について質問。

30人程度が月1回データ入力・必要ある場合修正を行い、月のレコード増加数は300程度。
管理側で入力データを過去データと照合の上チェックしたり、各文書の作成等を行います。
上記を前提にAccessを下記のように分けます。
Access-1(過去データ蓄積/テーブルのみで、他全てのAccessがリンクテーブルとして使用)
Access-A(データ入力・編集・過去データ閲覧用)利用約20名(入力時期は分散させる)
Access-B(Aと同じ)10名弱
Access-C(入力は過去データ呼出流用一括処理・編集・過去データ閲覧)1名
Access-2(管理用・ABCのデータ吸上げ、文書生成・過去データと照合・処理済データを過去データDBに移す…他)4名

本当はもっと複雑ですが、この時点でAccessの構築として現実的といえるでしょうか?
なるべく管理しやすく、安定性もはかりたいと思っていますが
Access経験が浅く、多人数向のAccess作成は始めてで、基準がわかりません。
問題点のご指摘や、アドバイスをお願いします。
又こうした作成に関して、参考になる具体的な記事のURL、書籍等ありましたらご紹介下さい。

回答の条件
  • URL必須
  • 1人2回まで
  • 13歳以上
  • 登録:2010/10/23 21:40:47
  • 終了:2010/10/24 20:45:23

ベストアンサー

id:akaired No.3

akaired回答回数33ベストアンサー獲得回数42010/10/24 19:18:38

ポイント45pt

同じような規模のシステムをAccess2003で作って運用しています。私のところでは10人程度がアクセスしてデータの参照、書き込み、削除などを行っています。キチンと設計をすれば30人程度でも耐えうるシステムは作れると思います。ただし、データがたまってくると遅くなるのは覚悟しないといけません。

10万件程度のデータを管理していますが、いまのところ障害が起こってmdbファイルが消え去ったということはありません。ただ、怖いので毎日バックアップは自動でとっています。アクセスの限界が少し見えたので、MySQLにデータを移そうかと思っています。

なので、将来的にMySQLなどに移したいんであれば最初からMySQLを意識した作りにしないといけません。例えば、DAOではなく、ADOなどを使うなどしてです。

あくまで私の考えですが、30程度であればAccess2003でいけると思います。でもバックアップだけはこまめにしてください。

ちなみにアクセスの限界は下記の書籍にかいてありました。

中小企業向けAccess 開発実践ノウハウ

この書籍には確か、25人程度でのアクセスであればSQL ServerよりAccessを使ったほうがいいんじゃないみたいなことが書かれていました(もちろんどんな使い方をするかにもよりますが)。

id:honoka_753

具体的な回答とアドバイス、参考書もありがとうございました。

近しい規模の運用されているの方の回答をいただけてほっとしてます。

偶然同じシリーズの 開発現場ワザ を買ったばかりだったのですが、中小企業向けAccess 開発実践ノウハウも目を通してみようと思いました。

毎日のバックアップは他のデータも含め随時行っていますし、蓄積したデータも必要あればある程度の時点でツール管理下から切り離しても問題ないようなので、慎重に作ってみようと思います。ありがとうございました。

2010/10/24 20:40:27

その他の回答(2件)

id:heke2mee No.1

heke2mee回答回数162ベストアンサー獲得回数432010/10/24 00:09:51

ポイント30pt

ACCESSで同時アクセスも出来ますが、安定性を考えるなら

データベースにSQL Server Express(無償版) 使用し、

入力側にACCESSを使用するのがいいと思います。


SQL Server Expressについては、こちらを参考にしてください。

http://www.atmarkit.co.jp/fwin2k/tutor/sqlexplmt/sqlexplmt_01.ht...


同時入力を前提として作るのであれば、データベースのロックやデッドロックについても

勉強したほうがいいと思います。


SQLについては、こちらが参考になるのでないでしょうか

(記事が古いので画面イメージなどは違っています。)

http://www.atmarkit.co.jp/fnetwork/rensai/sql01/sql1.html

* 第1回 SQLの基礎 「SELECT」文を覚えよう

* 第2回 SELECT文で並べ替えを行うには?

* 第3回 集計を行う「GROUP BY」句

* 第4回 異なるテーブル同士を結合する「JOIN」句

* 第5回 テーブル結合の仕組みを理解する

* 第6回 テーブル結合のバリエーションを増やす

* 第7回 SELECT文の結果を抽出条件に使う

* 第8回 サブクエリーの応用「相関サブクエリー」

* 第9回 SELECT文を統合するUNION

* 第10回 CREATE文でテーブルを作成する

* 第11回 CREATE文をさらに使いこなそう

* 第12回 データの登録を行うINSERT文

* 第13回 テーブル中のデータ識別に必要な主キー

* 第14回 データの更新と主キーの重要性

* 第15回 「ビュー」の作成でDB参照の利便性をアップ!

* 第16回 GUI環境で「ビュー」を作成してみよう!

* 第17回 DBにアクセスできるユーザーを制限する

* 第18回 グループ単位でDBへのアクセス権限を設定するには?

* 第19回 システム・ストアドプロシージャを活用しよう!

* 第20回 ストアドプロシージャを作成/実行してみよう

* 第21回 条件分岐のあるストアドプロシージャを作成する

* 第22回 ストアドプロシージャによる繰り返し処理

* 第23回 ユーザー定義関数を作成するストアドファンクション

* 第24回 テーブルで複数の処理を実行させるトリガー

* 第25回 トランザクションでデータの不整合を防ぐ

* 第26回 トランザクションを用いて注文登録をする

* 第27回 トランザクションの一貫性を保証するロック

* 第28回 SQL Serverで「デッドロック」を回避する

id:honoka_753

会社指定アプリ以外の導入は、申請が必要で現実的には厳しそうなのですが、個人的には興味深い内容で可能性のひとつとして参考になります。回答ありがとうございます。

以下は返信じゃないのですが、上記質問に補足です。

Access2003使用。

要求を考えると、Access以外を利用した方がいいとも個人的には思いますが、環境的都合上、Access利用前提でお願いします。

イントラネットの利用は現在の部署と、自分の立場上難しいです。

ネットワークドライブ自体もっと空きがある安定した場所を依頼してますが難しそうです。

引き続き回答募集しています。

2010/10/24 00:37:22
id:a-kuma3 No.2

a-kuma3回答回数4365ベストアンサー獲得回数18012010/10/24 08:35:59

ポイント5pt

本当はもっと複雑ですが、この時点でAccessの構築として現実的といえるでしょうか?

なるべく管理しやすく、安定性もはかりたいと思っていますが

僕の回答も期待するものにはなって無いと思いますが、Access は止めておいた方が良いです。

もともとスタンドアロンで使うことしか考えられてない(のだと思う)ので、ファイルの同期が甘く、複数で使うと、すぐ mdb ファイルが壊れます。


最悪なのが、mdb ファイルをネットワークで共有しておいて、それをクライアントの Access から直接参照/更新するような場合。

毎日更新がかかるような感じなので、ひと月もてばいい方だと思います。


繰り返しになりますが、安定性をはかるなら、Access を使って組む時点で、現実的ではありません。


http://www.microsoft.com/

id:honoka_753

具体的な回答ありがとうございます。

>安定性をはかるなら、Access を使って組む時点で、現実的ではありません。

その通りだと思いますが、Accessが前提となってしまっているので、多少壊れても、修復で直ぐ治るならいたし方ないかもしれません…。

不安定な中でもなるべく安定性もはかりたく思いそう書きましたが、マシにしたいと書くべきでした。紛らわしくてすいません。

又、ひと月で300レコードは増加率としてそんなに高くないと思い、まだなんとか可能ではかと思ったのですが…それでも厳しいということですよね?

mdbファイルをネットワークサーバー上、クライアントのAccess がCドライブ上ではいかがでしょうか?同じでしょうか?

mdb ファイルが壊れるのを回避するため、最適化をこまめにする事。

ファイルが壊れるリスクを下げるため、Accessへの同時接続人数を抑え分散させる事。

蓄積させる過去データは管理側以外は参照のみとすること。

Access-A・Bについては、入力した不確定データを個々のAccessで一時的に保持し、確定情報となった時点で、管理側が一括で吸上げをし、A・B側でAccessからAccessへデータを移す作業は行わない。

mdbファイルをテーブルのみと、フォーム・クエリ・レボートになるべく分ける事…等、なるべく工夫してみるつもりなのですが、それでもやはり運用するには現実的ではないということでいいでしょうか?

他に工夫できること、心がける事があればと思ったのですが。

2010/10/24 13:34:57
id:akaired No.3

akaired回答回数33ベストアンサー獲得回数42010/10/24 19:18:38ここでベストアンサー

ポイント45pt

同じような規模のシステムをAccess2003で作って運用しています。私のところでは10人程度がアクセスしてデータの参照、書き込み、削除などを行っています。キチンと設計をすれば30人程度でも耐えうるシステムは作れると思います。ただし、データがたまってくると遅くなるのは覚悟しないといけません。

10万件程度のデータを管理していますが、いまのところ障害が起こってmdbファイルが消え去ったということはありません。ただ、怖いので毎日バックアップは自動でとっています。アクセスの限界が少し見えたので、MySQLにデータを移そうかと思っています。

なので、将来的にMySQLなどに移したいんであれば最初からMySQLを意識した作りにしないといけません。例えば、DAOではなく、ADOなどを使うなどしてです。

あくまで私の考えですが、30程度であればAccess2003でいけると思います。でもバックアップだけはこまめにしてください。

ちなみにアクセスの限界は下記の書籍にかいてありました。

中小企業向けAccess 開発実践ノウハウ

この書籍には確か、25人程度でのアクセスであればSQL ServerよりAccessを使ったほうがいいんじゃないみたいなことが書かれていました(もちろんどんな使い方をするかにもよりますが)。

id:honoka_753

具体的な回答とアドバイス、参考書もありがとうございました。

近しい規模の運用されているの方の回答をいただけてほっとしてます。

偶然同じシリーズの 開発現場ワザ を買ったばかりだったのですが、中小企業向けAccess 開発実践ノウハウも目を通してみようと思いました。

毎日のバックアップは他のデータも含め随時行っていますし、蓄積したデータも必要あればある程度の時点でツール管理下から切り離しても問題ないようなので、慎重に作ってみようと思います。ありがとうございました。

2010/10/24 20:40:27

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません