プロが教えるわが家の防犯対策術!

現在、商品マスタDBの開発を検討しています。商材の追加が月100件程度あり、更新も結構頻繁に発生します。使用者が、10人程度のためアクセスのDBをファイルサーバー経由で共有する形をとりたいと考えていました。
しかし、マスタ登録前の商談中の商品に関しても簡単に登録し、情報共有できるツールにしたいという追加の要件がでてきました。その場合、このツール上で商談中の商材を仮登録し、商談終了後にマスタ登録の承認を含めた一連の業務フローに対応する必要があります。アクセスではこのフローへの対応が出来ないのではないかと考えています。Notesのような感じのソフトで、安価で開発できるものはないでしょうか。予算は、50万から70万程度を見込んでいます。ユーザーは10人程度を想定しています。ご存知の方ございましたら、ご連絡をお願い致します。

A 回答 (7件)

具体的な業務が分からないので想像していますが、商材の属性に商談中(仮登録)か本登録なのかという属性値を付ける訳にはいかないのでしょうか。


それならば1つのマスターの中で処理できると思います。
また、仮登録と本登録ではそれぞれ変更できる項目などは異なるメニュー(画面)で提供すれば別のマスターのように表現できます。
これは仮登録の商材を先取りして本登録分と一緒に検索したり請求書(見積書)に起こしたりするためです。
仮登録と本登録のデータベースをまったく分離して、必要な部分だけを本登録に移行できたら良いというのなら、データベースからデータベースへの写し込みを処理するだけなので、どんなデータベースでもできると思います。

この回答への補足

商談中のフラグを立てておいて、本登録時にマスタとしてこのフラグを消すという(もしくはその逆)方法ですね。
仮登録中(商談中)は、バイヤーが比較的頻繁にDBへアクセスし情報入力、参照します。本登録後は、完全に参照のみにしたいと思っています。仮登録中はバイヤーが4,5人程度で随時書き込みを行ったりしますので、ここら辺の制御が、アクセスで対応可能なのかイマイチ不安です。
仮登録と本登録のデータベースをまったく分離するという方法は、別DBで作っておいてあとでデータのインポートのような作業で本登録を行うイメージでしょうか?こちらであれば、最悪仮登録側のDBが破損してもダメージは小さく抑えられそうですね。

補足日時:2005/04/17 21:58
    • good
    • 0

登録した商品が仮登録かどうかについては、それを判別


するフラグの項目を追加すればよいかと思います。

ついでながら、Accessは止めた方がいいですね。
信頼性に今ひとつ疑問があります。
特にファイル共有している環境で、DB破壊が起きる
という現象を、何度も耳にしています。

フリーで信頼できるDB(例えばPostgreSQLなど)に
データを登録し、アクセスは入力用途だけに限定する
方がよろしいかと。

予算が50万から70万ということですが、SI業者に
発注してみてはどうでしょうか。(こういう低額の仕事は、
あまりやりたがらないと思いますが)

この回答への補足

PostgreSQLとは、Oracleの無料版みたいなイメージでしょうか?その場合、Accessはユーザーのインターフェース機能のみ持つことになるのですか?
お恥ずかしいのですが、生憎社内にシステム管理者がいないので、あまりシステムが高度な仕組みになると運用に耐えれないという実情があります。。。
今お付き合いしているSI屋さんがいますので、見積もりは取ってみようかと思います。ありがとうございます。

補足日時:2005/04/17 22:04
    • good
    • 0

使用者が10人でも、20人でも、


1つのテーブルへの同時アクセス数が2人程度なら、
簡易的なクライアントサーバー形式でやれば
Accessでも十分対応できるとは思います。

毎秒3人が、同時にレコード追加するような場合は
ちと苦しいです。
以前試しました。

なお、その場合、テーブルを普通に共有するのはまずい
ですので、

・サーバー用にテーブル専用ファイル、
・クライアント用にフォーム等専用ファイル。テーブル専用ファイルのリンクテーブルを使う。

というかたちで分ける必要があります。

また、

・クライアントのフォームで行ロックを使う

ということも必要だと思います。
行ロックはデータベースの識者から見ると不満のある
行ロックらしいですが、常時接続数が2~3程度なら
充分使えると思います。

それから、必要なら、例えば入力・更新系のフォームで
・連結フォームの使用を極力避ける。
ということもしなければならないかもしれません。
(経験上、同時接続2,3人、書き込み頻度15分に1件程度なら
連結フォームでもOKですが・・・)

なお、OSがWin2000以上などですと、へんなチェックが
入るのか、リンクテーブルのパフォーマンスが極端に落ちますので、
値を入力しないダミーテーブルをつくり、それをソースに
したフォームをつくり、それをクライアントファイルオープン時に
AutoExecマクロか、何かのフォームと一緒に、
隠し表示設定(acHidden)で開いて、Accessを終わらせるまで
開きっぱなしにしておきます。
そうすると、とりあえず、ローカルでスタンドアロンで
使うのに近いくらいのパフォーマンスが出ます。

常時接続数が2人程度で、書き込みも10分~15分に1件くらいなら
営業時間中に大量書き換えやループ処理などをしなければ
Accessでも充分いけます。

逆に、もし、常時、3~5分おきに同時に5人前後がレコード追加、や
検索などをガシガシやるようなら、
Accessにおまけで付いているSQLServerのミニ版の
「MSDE」を使うと無料です。(MSDE2000)
MSDE2000はSQLServer2000とほとんど同じで、多くの
システム屋さんが使用しているプロ対応できる製品です。
(とくにグループウェア系のシステム屋さんが
結構多く使ってます。もちろんMySQLやPostgreSQLも。
ただ、Accessと親和性が高いのはMSDEです。)

マイクロソフトのサイトからも最新版が無料でダウンロードできます。
MSDEの入門はこちらが非常にわかりやすいです。

●AccessユーザーのためのSQLServer/MSDE Client/Server入門
http://www.sqlpassj.org/bunkakai/begin/series/de …
1つのテーマにつき、下方にに10ページ分くらいのリンクがあり、
画像付情報が満載です。

●上記サイトとMSのジョイントページ
こちらも図が豊富で超わかりやすいです。
http://www.microsoft.com/japan/msdn/sqlserver/co …
認証方法のコントロール方法など、色々と書いてあります。
例えばこちら
http://www.microsoft.com/japan/msdn/sqlserver/co …
(SQL Server 2000 のユーザーと権限。MSDEにもそのま使えます。)
☆コラム「高信頼性データベース エンジンとは?」
http://www.sqlpassj.org/bunkakai/begin/series/s0 …

●MSDEでSQLServer用のデータベース管理ツールを使う
http://www.sqlpassj.org/bunkakai/begin/series/s0 …
(SQLServer120限定版に付属の管理ツールを使いますが
管理ツール自体には使用期限は無いようでそのままずっと
使えてしまいます。)

●HTTP経由でデータアクセスページ、OS制限を越える
http://backno.mag2.com/reader/BackBody?id=200502 …

MSDEはよく「”5ユーザー接続以下での使用に最適化だから”5人以上が
同時につなぐと遅くなるよ」ということが言われますが
それもPen2の300MHz、Pen3の500MHzCPUの時代の話ですから、
もしかしたら今(2G以上マシン)はそんなこともあまり
関係なく、オッケーなのかもしれません。
(前述のようにダミーテーブル等を作ってみるとか)
Accessでも5人くらいは同時接続してても(追加・更新しなければ)
別に遅くないですから。

また、MSDEはSQLServerとほぼ同じくらいのパフォーマンスを
持っているかも?という話もあります。

●多数ユーザー接続時におけるMSDEのパフォーマンスについて
http://www.akizuki.co.jp/msde/
グラフ付


というとで・・・
お金がもったいないということでしたら、今すぐダウンロードして
同時書き込みパフォーマンステストすれば良いでしょうし、
時間がもったいないのでしたら、個人システム業者でMSDEを扱うところを
探すと割と安くあがるかもしれません。

MSDEはAccess、PHP、ASP、などから接続できます。
    • good
    • 0

すみません。


肝心のMSDEダウンロードページを書き忘れました。

http://www.microsoft.com/japan/sql/msde/download …

このページには
MSDE は以下のようなソリューションに適しています。
・データベースを組み込んだクライアントアプリケーション
・接続数が25 を超えない Web サイト
・データベースを組み込んだアプリケーションの構築をこれから学ぶ方

と書いてあるので、同時接続5という話は過去のものとなったのでしょうか?(よくわかりません。)

マイクロソフトのMSDE専用サイトはこちら。
http://www.microsoft.com/japan/sql/msde/

MSDEならインターフェイスはAccessが一番らくちんかと思います。また、トリガやストアドプロシージャなどももちろん使えますのでパフォーマンスを重視した構築もできます。

ASPやPHPなどでも簡単につなげ、便利ですが、ASPやPHPはHTMLタグを
知っていないとちょっと面倒くさいのと、
Accessのようなかなり自由度の高い(?というか強引で無理やりな?)
インターフェイスを作ることは困難です。
(HTMLタグに慣れてないと時間がかかります。
またブラウザでは数千件もの一覧表を瞬時に表示したり、
サブフォームを埋め込んだりが面倒です。また、
連結フォームは作成できません。
デバッグ機能は段違いにAccessの方が良いと思いますです。ブラウザからのデータ入力が必要な場合は、データアクセスページ(OWC利用)とIISを使えば、ASPやHTMLの知識が無くとも、瞬時にWebページ画面、ピボットテーブル埋め込みWebページなどを作成できます。
データアクセスページは、httpアドレス経由でアクセス
不可能なゴミオブジェクトと思われているふしがありますが、
方法があまり紹介されていないだけで実際にはそんなことはなく
http://www・・・でのアドレス指定で普通にアクセスできます。



最終的には、作成しようとするデータベースシステムの仕様にもよりますので、
Access+MSDEが絶対に良いというわけではありませんが、
現状、他の言語をマスターできていないのでしたら、
かつ、ご自分で作るしかなくなってしまった場合は、
Access+MSDEは、まず選択肢の第1番目に来るのだと思います。

参考URL:http://www.microsoft.com/japan/sql/msde/download …
    • good
    • 0
この回答へのお礼

非常に詳細なコメントを頂きましてありがとうございます。
Access、ASPは大学時代にかじった程度なのでいまひとつ自信はないのですが、他に経験のある人もおらず、私が対応するしかなさそうです。ベンダーに依頼することも視野にいれて対応を検討したいと思います。
また、ユーザーでのDB共有についてですが、単純にファイルサーバー上にこのDBを置いておき、1人しか開けないようにするのはまずいのでしょうか?MSDEの学習に少し時間がかかりそうな為、順次クライアント-サーバー系に移行するような方法を取りたいと考えています。

お礼日時:2005/04/18 07:13

#1さんがおっしゃる通りで何の問題もないかと考えます。


仮登録か本登録かの区別のつく状態をテーブルに持たせておく。

MadeInTokyoさんの疑問はアクセスの機能で十分解決できます。

ユーザーによって参照のみにすることや、見えなくすることやボタンを消したり、フォームを消したり、操作不能にしたりなどなど、まず不可能と思われることはAccessに無いと思って結構です。

それから、DBを仮登録と本登録で分けることはしません。
ひとつで結構です。

また、この程度のユーザーであればAccessDBの信頼性も問題ないと思います。
DBがときどき破損することがありますが、「修復機能」をかければ問題ありません。必要であれば自動修復もかけられます。
DB使用中にテーブルをいじったり、プログラムの作り方が極端に悪くない限り、修復不可能に陥ることはまず無いです。

ひと時も絶対にDBが落ちる瞬間があってはならない!という次元のプロバイダーのような管理をお考えでしたら、他の方々が言われている方法を使用し、Accessは避けられた方が無難です。
ただし、費用を桁違いに出し外注するか、ご自身が専任され昼夜問わずプロ同等の管理を行っていくこととなります。

その他、疑問点がありましたら具体的にご質問ください。
    • good
    • 0
この回答へのお礼

なるほど。基本的にいつ落ちてしまっても構わない程度なので、アクセスで十分対応可能ということですね。とりあえず、要件を絞りながら順次自社内で開発していくことにします。ありがとうございました。

お礼日時:2005/04/18 13:44

>ユーザーでのDB共有についてですが、単純にファイルサーバー上にこのDBを置いておき、


>1人しか開けないようにするのはまずいのでしょうか?

排他的にmdbファイルを開いていくということですね。
それでしたら全然まずくはないです。

でもファイル丸ごとをネットワーク越しに開くのは
ネットワークにもサーバマシンにも負荷がかかってしまうし、
破損の確率が上がってしまうので
やはり、data専用(テーブルのみ)のmdbファイルをサーバーに配置し、
プログラム専用(サーバーへのリンクテーブル、クエリ、
フォーム、レポート等)のmdbをクライアント側に
配置した方が良いと思います。

排他処理はいろいろなケース(現場の要望)とそれに
あわせた方法が考えられますので、こちらはまたいろいろと
試されたあとに、不明点が出てきてから、別の
質問をたてて聞かれた方がより詳しい情報が
得られると思います。
基本的には閲覧は自由で書き込み時だけ排他的にする
という方法が使いやすいとは思いますが・・・。
(方法としては、ツールのオプション・詳細で設定する方法や
ldbファイルを読みに行く方法や、
自前でロック機構を作る方法、
Accessのユーザー別のセキュリティ機能を利用する方法などがあります。)

あと、僕が前回書いた「リンクテーブルが遅い」という
部分ですが、誤りで、
「サーバーアクセス2台目以降のリンクテーブルオープン、クエリ動作が遅い」
ということでした。
1台目はそれほど遅くありません。

ただ、これは前回も書きましたとおり、サーバーがわに
ダミーテーブルを作って、
クライアントがわにそれをもとにしたリンクテーブルを
作成後、
さらにそれをモトにしたダミーフォーム等を作って
隠し設定で開きっぱなしにしておけば、かなり
改善されます。
あとは、IN句を使ったクエリをリンクテーブル代わりに
するとか。
この場合も2台目以降のアクセスでもテーブルが開く速度が
ほとんど正常になります。
なお、このような処置は、Win98上では必要ありません。
Windows98は何もチェックが入らないのか良く知りませんが
リンクテーブルが遅くならないので・・・


また、ダミーテーブルを作るとローカル・スタンドアロンと
同じくらい速くなるというのも誤りでした。すみません。
1台目でサーバーのテーブルを開くのとほぼ同じ速度になる・・・
というのが正しいです。
ちょっと混同してしまいました。
いずれにしても、遅くは無いので実用可です。
    • good
    • 0

書き忘れましたが、最適化は



・まずいったんバックアップをとる
・その後最適化。
・バックアップを捨てる

という手順で、おこなってください。
というのもごく稀にAccesssは最適化に失敗するからです。

回数は1日~2日に1回やれば十分すぎるほど充分です。
ただし、必ず定期的にやってください。
あまり期間をあけすぎると破損することがあります。
(修復でも直らないケースもあります。)

また、
・クライアント側からVBAでサーバー側のmdbを最適化する
・閉じるときに毎回最適化する設定にする
などは小さなmdbのみで、1万件以上データを持つことが
予想されるmdbではやらない方が破損の確率は減ると思います。
サーバーがわのmdbの最適化は、必ずサーバー上で行ってください。



こんなことしなくても運がよければ問題ないのですが
運が悪いと大事なデータを失う羽目になりますので
一応万が一の保険ということで、ご留意ください。

バックアップは、前日、前前日の2部は最低とっておく
形がいいと思います。

あとリンクテーブルが頻繁に破損するときは、LANカードのドライバが関係しているときもあります。
OSについている汎用的なものを使っている場合は、
カードに付属するものに変更する、もしくはその逆の場合なら、最新のドライバに変えてみるなどです。
    • good
    • 0
この回答へのお礼

リンクの貼り方や最適化など、少し自分の知識を越えている部分がありますので、順次学習しつつ対応していこうと思います。非常に参考になりました。ありがとうございます。

お礼日時:2005/04/18 13:47

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す