ACCESSを利用した顧客管理

現在、社内の顧客管理システムを構築しようと検討中です。
管理する内容としては、営業の折衝履歴、見積情報等で、人数は５人前後での使用を想定しています。
まずは、ACCESSにてデータベースおよびフォームを作成し、「データベースの分割」機能を利用し、バックエンドデータベースをファイルサーバに置いておき、社内で各営業のPCからACCESSでアクセスする様な運用を考えています。
フォーム部分については、私の場合、他の言語よりACCESSでの作成の方が開発期間が短縮出来そうですのでACCESSで作成したいと思っています。
しかし、この方法(ファイルサーバにバックエンドデータベースを置いて共有する方法)での運用について色々調べてみますと、ファイルの破損や処理速度等に関して不安が残る様でしたので、最初はバックエンドデータベースをACCESSのままで試し、問題が出て来たらバックエンドデータベース部分をSQLServer等別のDBに置き換えて対応出来ればと思うのですが、DB置き換え後のテーブル構造が一緒であれば、フォーム部分については使いまわす事は可能なのでしょうか？また、置き換えるDBをSQLServerにする場合は、MySQLやPosgreSQL等他のDBに比べ、移行作業は大分楽なのでしょうか？

No.3 ベストアンサー 回答者： t2hayashi 回答日時： 2007/11/29 12:21

質問者様の思想で全くもんだいありませんよ。

インターフェイスＭＤＢとデータベースＭＤＢに分けてリンクテーブルで運用、将来的にデータベースＭＤＢをＤＢサーバーに。

何ら問題ありません。頑張ってください、
経験上移行も非常にスムーズです。

ただもし、現時点でＤＢサーバーをお持ちならば運用は
ＤＢサーバーでされることをオススメします。

アクセスのアップサイジングウィザードなんかは意外と
簡単にコケますので。

個人的に好きな開発手法は

1.スタンドアロンで開発
2.テーブルをＤＢサーバーにエキスポート、テーブルをリンク
3.最終チューニング
4.運用
5.その後テーブルの変更や追加などあれば直接SQLサーバーで作業
し、随時リンクテーブルをリフレッシュ

です。

MDBとSQLサーバーではテーブルの型などが微妙に違いますので
散々運用した後にSQLサーバーに移行するのは意外と骨が折れます。

またSQLサーバーが最初に用意できるならADPも視野に入れられますね。



＞ADO接続で無いと駄目なのでしょうか


ぜんぜんそんなことありません。
私はリンクテーブルでDAO運用してますが、50人で使う基幹システム
がサクサク動きます。

一番大事なのは設計時の思想と最適化です。

この回答への補足

ご回答どうもありがとうございます。

> 個人的に好きな開発手法は
>
> 1.スタンドアロンで開発
> 2.テーブルをＤＢサーバーにエキスポート、テーブルをリンク
> 3.最終チューニング
> 4.運用
> 5.その後テーブルの変更や追加などあれば直接SQLサーバーで作業
> し、随時リンクテーブルをリフレッシュ
>
> です。

この流れはまさに私が描いている開発手法になるのですが、
まずはスタンドアロンで開発し、「データベースの分割」機能を利用してインターフェイスMDBとデータベースMDBに分けて、データベースMDBをファイルサーバに置いてリンクテーブルで運用するだけであれば、ADOやDAOを意識する必要はないと思っています。(逆に言うと、どういった場合にADOやDAOが必要になるのかがいまいち理解出来ていません)
しかし、データベースMDBをSQLServer等のDBサーバに移行する場合、ACCESSのテーブル接続処理にADOやDAOを使っていないと、その部分の処理の作りこみが発生するのか？もしくはリンクの設定、DBの違いによる修正を行うだけで済むのかが分からない状態です。
ひとまずSQL Server 2005 Express Editionをインストールしてみましたが、初めてSQL Serverを使用すると言う事もあり、理解するのに時間がかかりそうです。
当然私の理解力にもよるのですが、
・最初からDBにSQL Server 2005 Express Editionを使用して開発(SQL Server)
・まずはACCESSのみで開発し、運用を行いつつSQL Server 2005 Express Editionへ移行
だったらどちらがお勧めなのでしょうか？
分かり辛い文章かも知れませんが、よろしくお願いします。

補足日時：2007/11/29 17:16

No.4 回答者： t2hayashi 回答日時： 2007/11/30 12:44

NO.3です。

>まずはスタンドアロンで開発し、「データベースの分割」機能を利用してインターフェイスMDBとデータベースMDBに分けて

私は「データベースの分割」機能って使ったことありません。
テーブルを他のMDBにドラッグアンドドロップで移行して
リンク貼るだけです。

＞ADOやDAOを意識する必要はないと思っています。(逆に言うと、どういった場合にADOやDAOが必要になるのかがいまいち理解出来ていません)

私はDAOメインなのですが、本格的なアプリケーションを開発する場合
DAOを使えば圧倒的に速度が変わってきます。

たとえばDLOOKUPなどの関数を使ってテーブルから値を呼び出すのと
DAOを使ってレコードセットから値を呼び出すのとでは天と地の
スピード差があります。
そしてこれはSQLサーバー云々の話ではなく、スタンドアロンのシステムでも同じ。

つまりDAOはサーバーとの通信言語なわけではなく、あくまでも
レコードセットの呼び出しおよび操作言語であり、特に少人数での
データ共有（25名くらいまでかな）に向いていると言われていますが
しっかりと設計していれば500人が使うシステムでも問題ないと思っています。

簡単に言うと、クエリーなどを使わずにテーブルのレコードをある条件で仮想的に呼び出したり操作したりできる、と考えていただくと良いでしょうか。そしてDAOやADOでDBを操作するなら「SQLサーバーの堅牢性や速度」をより活かせるという感じでしょうか。

DAOについてはこちらを読んでみてください
http://www.accessclub.jp/dao/index.html


＞その部分の処理の作りこみが発生するのか？もしくはリンクの設定、DBの違いによる修正を行うだけで済むのかが分からない状態です。

厳密には色々ありますが、基本的にそのまま使えます。
データ型の違い（メモ型や日付型）を修正する以外はそのままいけますよ。リンクテーブルはローカルテーブルとほぼ同等に扱えますので。

＞・最初からDBにSQL Server 2005 Express Editionを使用して開発(SQL Server)
＞・まずはACCESSのみで開発し、運用を行いつつSQL Server 2005 Express Editionへ移行
＞だったらどちらがお勧めなのでしょうか？


どちらかといえば後者でしょうか。


・データMDB+アプリケーションMDBで運用。
・データMDBは毎日定時バックアップ。

していればまぁなんとかなります。
ただしMDBはいつか壊れますのでしっかりバックアップを取って
ユーザーのストレスが大きくなったらSQLサーバーへのスケールアップ
を考えられてはいかがでしょうか。

さらに開発時点でしっかりDAOなどでのVBA開発ができていれば
驚くほど簡単にスケールアップできるでしょう。


※おすすめの本としては
「中小企業向け Access開発実践ノウハウ 翔泳社・株式会社インフォース前野好太郎 著」です。
なぜACCESSで開発するのか？あたりから易しく書かれています。

この回答への補足

度々のご回答、どうもありがとうございます。

> 私は「データベースの分割」機能って使ったことありません。
> テーブルを他のMDBにドラッグアンドドロップで移行して
> リンク貼るだけです。

この様な方法でもテーブルのリンクを行うことが出来るのですね。勉強になります。

> 私はDAOメインなのですが、本格的なアプリケーションを開発する場合
> DAOを使えば圧倒的に速度が変わってきます。

なるほど。DAO等で接続することで処理速度や堅牢性を活かせると言ったメリットがあるのですね。ご指摘頂いた様に、運用時に速度面などでストレスを感じるようであれば、DAOやADOについて検討してみようと思います。

前回の補足内容記載後にSQL Server 2005 Express Editionをインストールし、あれこれいじってみたところ、ADPによるSQL Serverとの連携よりも、ODBCによるSQL Serverとのリンク(MDB)の方が、ACCESS単体で環境構築を行うのに近い感覚で開発出来そうでしたので、
・まずはスタンドアロンで開発
・テーブル部分を「アップサイジングウィザード」機能を使用し、SQL Server 2005 Express Editionに移行
・調整後、運用
と言った流れで開発を行っていこうと思っています。

> ※おすすめの本としては
> 「中小企業向け Access開発実践ノウハウ 翔泳社・株式会社インフォース前野好太郎 著」です。
> なぜACCESSで開発するのか？あたりから易しく書かれています。

この本について、Amazonで調べてみましたが、確かに今の私がちょうど必要と思われる内容がたくさん載っていそうですね。
早速購入してみようと思います。
どうもありがとうございます。

補足日時：2007/11/30 14:24

この回答へのお礼

DAOや運用について、色々教えていただきどうもありがとうございました。
ひとまず大まかではありますが、方向性が見えてきたので、回答を締め切らせて頂きました。どうもありがとうございました。

お礼日時：2007/11/30 14:29

No.2 回答者： nackfive 回答日時： 2007/11/29 10:46

５人程度だと　SQLServerをしなくとも何とかなりそうな気がしますが

不安であれば　最初から MSDEを使用すれば良いのではないですか？
（今はMSDEではなくSQLServerExpressになるのかも知れませんが。）
それであれば　SQLServerを購入する必要もないですし。
将来５人以上で処理することになった時点でSQLServerに変更されれば
宜しいかと思います。変更するだけで　移行作業はほとんどありません。

この回答への補足

ご回答どうもありがとうございます。
確かにSQLServerExpressなら無料ですので、確かに最初からACCESS+SQLServerExpressで構築すれば良さそうですね。
その方向でも少し調べてみようと思います。

補足日時：2007/11/29 15:24

この回答へのお礼

このご回答を頂くまで、SQL Server 2005 Express Editionを使用することは全く考えていませんでした。
早速インストールして、色々いじっているところです。
ご回答どうもありがとうございました。

お礼日時：2007/11/30 14:31

No.1 回答者： tarosan11 回答日時： 2007/11/29 09:10

自分の経験ですが、参考になれば。

。。

AccessでTry運用し、SQLServerへブラッシュアップは
段階的導入としては移行は比較的楽だと思います。
（MySQLやPostgeSQLでも大丈夫だと思いますが）
下記注意事項に留意してAccess開発するようお勧めします。
・テーブルへの接続は、「テーブルへのリンク」ではなく
　ADO接続で。
・フォームでのデータ処理はマクロではなくVBAで開発して
　おいた方が融通が利くと思います。（経験上）

あまり参考になりませんが、上記事項に沿って進めた際は
移行自体は一ヵ月も掛かりませんでした。
移行後、多少のトラブル／修正は発生しましたが、大事に
至る問題は起きませんでした。
がんばってください。

参考URL：http://www.accessclub.jp/index.html

この回答への補足

ご返答どうもありがとうございます。
一点お伺いしたいのですが、やはり将来的にSQLServer等別のDB置き換えを考慮する場合には、テーブルのリンクではなくADO接続で無いと駄目なのでしょうか？ACCESSでの開発は、SQL文や、ADOの様に接続を意識したコーディングをしなくてもDBを用いたアプリケーションを作成出来る事が魅力的だったのですが、やはりこれは一人で使用する場合での話になるのでしょうか？
極端な話、接続にADO接続ではなくテーブルのリンクを使用して作成したACCESSのフォームは、DBをSQLServerに置き換えるタイミングで、テーブルのリンク先を修正するだけの対応で済むといった事にはならないということでしょうか？

補足日時：2007/11/29 10:39

この回答へのお礼

結局最初からACCESS + SQL Server 2005 Express Editionにて運用を行う方向でやってみようと思います。
ご回答どうもありがとうございました。

お礼日時：2007/11/30 14:33