Access2013/フロントエンドとバックエンド

Access2013で、フロントエンドとバックエンドにファイルを分割し、ネットワーク上にバックを配置して、最高三人ぐらいの人数で使用するような形をとろうかと考えています。

この場合、アクセスはこわれたりすることはありうるのでしょうか？
また、普段のアクセスのメンテナンスの仕方について
ACCESSは、データの最大許容量が2GBとありますが、これに対する対応として、どのようなやり方があるか知りたいです。（レコードを削除したりするのではなく違う方法で）

私が考えているのに、MS SQL Serverに移行するという手段があります。
その他の対応方法を知りたいです。

よろしくお願いします。

No.4 ベストアンサー 回答者： f_a_007 回答日時： 2014/12/03 10:37

＞何しろ、ITの担当が私だけですので。

1人で全部作っていますから。

私も、設計からプログラミング、導入時のレクチャーを一人で担当してきました。各種伝票のレイアウトに印刷発注、事務所と工場のレイアウトの設計、原価計算の仕組みから売上計算システムの改変。超片田舎なもんで地元のソフトハウスにも、この手の開発経験者はゼロ。まあ、でも、一人でもできました。質問者もできますよ。

Q、(1)(2)については、どのような設計をされていましたでしょうか？
A、生データの編集とインポートを行うプログラムで対応。

出力部門によって生データのどれとどれが必要なのかは大きく違ってきます。ですから、各担当部署は、生データ蓄積データベースから適当な時間を見計らって必要なデータを利用しやすい形に加工しつつインポート。加えて、独自に入力すべきデータの入力処理を行った後に、必要な演算と出力を行ってきたと記憶しています。なお、生データ蓄積PCと各部門PCとは、サーバーで共有すべきデータについても吐き出していたんじゃーないかと・・・。

＞バッチのようなものを作り、それを深夜実行する。

これは、MS-DOS時代のやり方。今の時代、どんなに大量のデータであっても数十秒で加工しつつインポートすることができると思いますよ。

PS、できれば的を絞って再質問されて本当のプロからのアドバイスを！

この回答へのお礼

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

回答者様も、ご自分で全部お作りになられていたのですね。関心させられました。

取り敢えず、今の段階では、受注から工事発注、一受注毎の生産、請求処理まで作りたいと思います。
その後、恐らく在庫管理システムを別DBでつくろうかなと。
その後・・・

今後共、よろしくお願いします。

お礼日時：2014/12/03 18:01

No.3 回答者： f_a_007 回答日時： 2014/12/02 20:29

例えば、

1. 受注 + 見積 + 精算 + 請求(1受注単位）→テーブルと、フロントに分ける
2. 在庫管理　→テーブルと、フロントに分ける
3. 経理（月単位の入金確認、支払確認）→テーブルと、フロントに分ける

というふうに。

まあ、そういうことです。

が、分割・分散すれば、（その程度に応じて）それぞれのシステム間の相互参照、データ交換を必要に応じて必要なだけ実現するのか？という難題が生じます。それに、サーバーのみにデータベースを置くのでは必要とあらば幾つかの通常のWindowsマシンにもデータベースを配置することも視野に入れる必要があります。

私の場合は、MS-DOSデータベース⇒UNIXデータベース⇒Windows NT+Windows版データベースと３代を経ての分割・分散でしたから、割とスムーズに設計できました。が、質問者が、仮に初めてだとすると、最初から、SQL Serever での非分散・分割型が良いかもしれません。

なお、私は、プロのプログラマではありませんので・・・。全体に「ふーん！」程度で読み流されたがいいですよ。（決して、適当に回答している訳ではありませんが・・・）

この回答への補足

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

>>1. 受注 + 見積 + 精算 + 請求(1受注単位）→テーブルと、フロントに分ける
>>2. 在庫管理　→テーブルと、フロントに分ける
>>3. 経理（月単位の入金確認、支払確認）→テーブルと、フロントに分ける
>>というふうに。

>まあ、そういうことです。
>が、分割・分散すれば、（その程度に応じて）それぞれのシステム間の相互参照、
>データ交換を必要に応じて必要なだけ実現するのか？という難題が生じます。

個々で、私が考えたのは次の2点です。
1)データのやりとりの仕方
2)複数の分割されたDB間で、互いのテーブル情報をどのような形で参照するか

1)については
　a)バッチのようなものを作り、それを深夜実行する。
　b)アクセスで何か処理をした時に、他のDBに反映させる。
2)については
　a)必要なDBの必要なテーブルのリンクテーブルを作り使用する
　b)PGで、他のDBのデータを参照する

1)に関して
バッチの実行とエラーが発生した時のメンテナンスの作業などを考えると、非常に大変な気がします。何しろ、ITの担当が私だけですので。1人で全部作っていますから。
(b)も、反映漏れが出てくる可能性を考慮すると、やはりするならバッチかなと思いますが。
もしくは、分割はセずに、その後、SQL Serverに移行するのもありかと考えています。

2)については
　aのリンクテーブルを作ると、そのデータ容量分、ファイルの量が増えそうな気がしますが実際には、増えるのでしょうか？試してみなくてはいけませんが。

この(1)(2)については、f_a_007さんは、どのような設計をされていましたでしょうか。

よろしくお願いします。

補足日時：2014/12/03 09:23

No.2 回答者： f_a_007 回答日時： 2014/12/02 16:52

http://otndnld.oracle.co.jp/document/products/or …

いわゆる分散型データベースを模したということです。

１、営業・顧客よりの受注データベース。
２、工場への生産指示・売上管理データベース。
３、CAD・CAMのフロントデータベース。
４、在庫管理データベース。

UNIXデータベース⇒Windowsデータベースへの転換時に、いわゆる分散型データベースを模したということです。当時は、「WindowsやAccessは遅くて使い物にならない」と酷評されていました。でも、UNIXデータベースの後継システムは必要。分割・分散は苦肉の策ですた。

大雑把に言えば、

(1)生のデータを単純に蓄積するデータベース。
(2)生データからそれぞれに必要な部分をインポートし加工・出力するデータベース。

に分割したとも言えます。

この回答への補足

ご回答ありがとうございます。
ご指摘の1～4をみると、どうも、役目の違うテーブル自体を別々のDBにわけて、しかも、それぞれに、フロント + バックエンドを作るというように聞こえますが、そうしてもよろしいのでしょうか？

例えば、
1. 受注 + 見積 + 精算 + 請求(1受注単位）→テーブルと、フロントに分ける
2. 在庫管理　→テーブルと、フロントに分ける
3. 経理（月単位の入金確認、支払確認）→テーブルと、フロントに分ける

というふうに

ややこしいですが・・・

よろしくお願いします。

補足日時：2014/12/02 19:44

No.1 回答者： f_a_007 回答日時： 2014/12/02 12:26

Q1、この場合、アクセスはこわれたりすることはありうるのでしょうか？

A1、こわれた経験はありません。

が、こわれることあると思いますよ。
私が一番に重要視したのは、次の２点です。

１、不意の停電に備えてバックアップ電源を用意する。
２、夏冬の長期休み明けの再起動は室温が安定してから。

なお、バックエンドのPCのDBMは一日一回はバックアップしてクラッシュに備えていました。

Q2、ACCESSは、データの最大許容量の対応策。
A2、分割。

私の場合は、分割という対応を基本にしました。ですから、まず、一番に開発したのは、コントロールパネルと酷似したメニューシステム。そういうメニューの存在を Microsoft が、Windows アプリの基本要素だと言明していたので・・・。

＞私が考えているのに、MS SQL Serverに移行するという手段があります。

これは、いいですね。経験では、52倍速で動きます。ただし、Access2013では、あのADPのサポートが中止されました。ですから、ODBC接続に戻せば少し遅くなるかも知れませんね。もちろん、ハードの進歩で帳消しかも・・・。

PS、最新のWindowsPCよりも350MZのNT機がサクサク動く！

SCシステムを構築する場合、やはり、重要なのはサーバー機の性能とOS。「最新のWindowsPCよりも350MZのNT機がサクサク動く！」ということもありえます。一応、サーバー機の性能とOSの検討の必要性も・・・。

この回答への補足

ご回答ありがとうございます。
すみませんが、この「A2、分割。」と書かれているのは、フロントとバックエンドに分割すると言う意味でしょうか。
データ容量が2GBの制限がある場合に、分割する方法とは、どのようなことなのでしょうか。

よろしくお願いします。

補足日時：2014/12/02 13:43