Accessのフィールド数が255しかない=業務では使えない？

DBはもっぱら社外に出していたのですが、カスタマイズの問題から、自分でやろうと思い立ち、Accessでまずは売上明細書を作り始めております。

順調に進んでいくと、なんとフィールド数が255しかないことが分かって、ふとした疑問が沸きましたので、質問させてください。

・フィールド数255というのは、明細書にとってはあまりにも少ない（品名/数量/単価/金額/備考だけで5つも取られる）。
これはやはり本格的な業務レベルでは使えないということでしょうか？

・AccessはDBですが、一度に複数の人間（5人以上）が使っても耐えますでしょうか？

質問が馬鹿すぎて自分でも笑えますが、ググってもなかなかよい答えが見つからなかったので、質問させてください。
どうぞ宜しくお願いします。

No.7 回答者： gatt_mk 回答日時： 2006/08/29 13:06

>DB、Accessに関しては、他アプリと比べても若干情報量が少ないので、とても参考になりました。

ACCESSに関するサイトはかなりたくさんあります。いくつか参考になりそうなものをあげておきます。他の方の質問や回答を読むだけでもかなり勉強になります。上級者向けのサイトもありますが、そうしたサイトの内容が理解できるようになれば上級者の仲間入りです。

http://www.naboki.net/access/
http://www.ruriplus.com/msaccess/bbs.asp
http://www.f3.dion.ne.jp/~element/msaccess/index …
http://www7.big.or.jp/~pinball/

この回答へのお礼

何度もご丁寧に！頭が下がりますｍ（＿＿）ｍ
記載頂いたURLも、ひとつひとつ参考にさせて頂きます。
Accessで情報量が少ないとか言ってたら、SQLはもっと大変ですよね。がんばります。

ありがとうございました！

お礼日時：2006/08/29 14:36

No.6 回答者： ipsum11 回答日時： 2006/08/29 11:38

皆さんの仰るとおりですね。

特に、No.5さんが言うように、テーブルの正規化やリレーションシップについて勉強してください。

>簡単に言えば、前工程、中工程、加工の明細がその一枚に入っており・・・
であるならば、少なくとも１つのテーブルを３つに分けられますよね？前工程テーブル、中工程テーブル、加工テーブル見たいな感じで。
そうすれば、２５５でも十分収まるはずですよね？

この回答へのお礼

おっしゃる通りです。
リレーションシップ、今まさに手こずりながらトライしています。

皆さん本当に親切ですね。DB、Accessに関しては、他アプリと比べても若干情報量が少ないので、とても参考になりました。

本当にありがとうございます。

お礼日時：2006/08/29 12:04

No.5 回答者： gatt_mk 回答日時： 2006/08/29 10:24

>簡単に言えば、前工程、中工程、加工の明細がその一枚に入っており、

それらの項目にそれぞれオプション項目が付いているので、
あっという間にフィールド数255になった→あれ？という感じなのです。

とのことですが、ACCESSに限らずRDBを利用したデータベース構築に際しては、一般的に1つのテーブルにすべての項目を持たせるようなことはしません。テーブルの正規化やリレーションシップについて勉強されたほうがよろしいかと思います。

テーブルの構造を理解して作成しないと根本的な間違いをしたまま作業をすすめる事になってしまいます。

この回答へのお礼

>一般的に1つのテーブルにすべての項目を持たせるようなことはしません。
ありがとうございます。リレーションシップですね。

これまでは、例えば‥
加工費A　数量A　単価A　金額A　備考A
加工費B　数量B　単価B　金額B　備考B
加工費C　数量C　単価C　金額C　備考C‥
とやっていたので、すぐにフィールドが埋まってしまっていましたが、
リレーションを使って、もっと上手く作れるようにします。

何度もご回答、ありがとうございました！

お礼日時：2006/08/29 11:36

No.4 回答者： 16August 回答日時： 2006/08/29 08:29

アクセスはあまり大きなＤＢには向いていません。

一度に５人以上で使われるのは、処理速度が極端に遅くなる恐れがあります。　Ｎｏ３の方もおっしゃっておられますが、排他制御がいまいちというのもちょっと問題です。　さらに、mdbが突然壊れてしまったり、テーブルの削除などを頻繁に行うとdbcompact を頻繁に行わなければいけなかったり、業務用のＤＢとしては、物足りない部分が多いです。　

ただし、とっつきやすい。　価格が安い。　簡単にSQL Serverにアップサイズできる。　などを考えると、あながち捨てたものでもないと思います。　

本格的な業務レベルで使うというのが、どの程度の処理内容なのかが問題です。　一時間に数十件の処理なのか、数百件の処理なのか、このあたりがアクセスが使えるかどうかの判断基準になると思います。

この回答へのお礼

具体的なご回答、ありがとうございます。
>とっつきやすい。価格が安い。簡単にSQL Serverにアップサイズできる。
>などを考えると、あながち捨てたものでもないと思います。
そうですね、私もDB入門にはAccessがいいのではないかと思っております。

Accessの次はSQLかと思うと、少し気の長い話になりますが、自社の利便を考えると、やるべきかなと思っております。

ありがとうございました。

お礼日時：2006/08/29 09:34

No.3 回答者： gatt_mk 回答日時： 2006/08/28 23:33

>・フィールド数255というのは、明細書にとってはあまりにも少ない（品名/数量/単価/金額/備考だけで5つも取られる）。

何故フィールド数が255というのが少ないと考えられたのでしょうか？数量/単価/金額/備考の５つがあれば少なくとも明細は作れますよね。フィールド数が255というのは１テーブルあたりということだと思いますが、確認されていますか？
テーブルはフィールドとレコードで構成されています。１件のレコードに関してフィールドは255ということです。レコードは数万件持っても問題はありません。レコードというのは納品書の１明細に相当するものです。五件の注文があれば１伝票あたり５明細（５レコード）になるということです。

注文が増えるほどレコードが増えていくということです。
注文が増えてもフィールド（明細の項目）が増えるということは通常ありません。

>AccessはDBですが、一度に複数の人間（5人以上）が使っても耐えますでしょうか？

どのように使うかによります。Excelのように同じファイルを同時に開くような使い方をしたらあっという間に壊れると思います。ネットワーク上で共有するにはそうした作成方法があります。
但しそうした場合でも同じレコードを同時に操作する場合などはかなり注意が必要です。（ACCESSは排他制御に関してはかなり弱いです）

この回答へのお礼

こちらもご丁寧にありがとうございます。
>何故フィールド数が255というのが少ないと考えられたのでしょうか？
>数量/単価/金額/備考の５つがあれば少なくとも明細は作れますよね。
はい、その通りなのですが、その5つのフィールドが、50ほどあるのです。
簡単に言えば、前工程、中工程、加工の明細がその一枚に入っており、
それらの項目にそれぞれオプション項目が付いているので、
あっという間にフィールド数255になった→あれ？という感じなのです。

>Excelのように同じファイルを同時に開くような使い方をしたらあっという間に壊れると思います。
このあたりも慎重に行きたいと思います。実務に使うものなので、
検証にも重きを置くことになりそうです。（検証って遊んでるように見られませんか？）

>ACCESSは排他制御に関してはかなり弱いです
はっきり分かったので、MySQLを視野に入れた動きをしたいと思います。

しかしDBって便利なだけに面白いですね。がんばります。

お礼日時：2006/08/29 09:07

No.2 回答者： Bubuca 回答日時： 2006/08/28 23:19

こんばんは

エクセルやファイルメーカーはよく触るのですが、アクセスはよく知りませ
ん。アクセスもデータベースですから、レコードとフィールドで構成されて
いると思うんです。エクセルならば行と列に当たるかと思います。
エクセルでも１シートで約３万２千行（レコード）の２５５列（フィール
ド）で全部のセルの数は８００万を超えます。

アクセスの２５５フィールドとは１レコードあたりではないでしょうか。
レコード数の最大はわかりませんがエクセルよりも少ないことはないでしょう。

レコード数が数万を超えるようになると処理速度はマシンの性能と処理手順
の手際によってかなり影響を受けるかもしれませんが、データベースを謳っ
ているソフトですから、業務に使えないはずはないと思います。
いままでいろいろなデータベースを作ってきましたが、あまり大きい場合に
はリレーションを使って別ファイルにしてしまうこともあるので、１レコー
ドで２５５フィールドを超えるようなものは見たことがありません。

この回答へのお礼

ありがとうございます。
エクセルで帳票はよく作るのですが、DB化することはなく、あくまで実伝票のデザイン→エクセルに移行でよかったのです。
その考えをそのままAccessに持ってきて、フォームでデザイン→フィールドをどんどん埋め込み→フィールド足りない‥。となってしまったという浅はかさです‥。

>いままでいろいろなデータベースを作ってきましたが、
>あまり大きい場合にはリレーションを使って別ファイルにしてしまうこともあるので、
これを一度実行してみようかと思っております。

大変参考になりました。ありがとうございます。

お礼日時：2006/08/29 08:57

No.1 回答者： noname#25358 回答日時： 2006/08/28 22:50

　プロのプログラマーやっております。

　特殊技術に関する特別なデータテーブルならともかく、単なる明細書で２５５項目は多すぎです。
　アクセスの仕様ではなく、テーブルの設計に問題があると思われます。
（そんなに多くの項目がある明細書を、本当にお客さんにペラで見せるのですか？　項目分類もページ分けもせずに？　ということです）
　正規化するなどの方法で減らせないか検討してみてください。

　Access に使われている JET エンジンは信頼性に関しては一般事務程度に使える程度に確保されています。
　ですが、圧倒的に重いので、何人もの人間が同時にアクセスしにくるようなシステムには向かないでしょう。

　もしお金の問題が絡むなら、せめて MySQL を候補に入れた方がいいです。

この回答へのお礼

ご回答ありがとうございます。
>特殊技術に関する特別なデータテーブルならともかく
今回の場合、これに該当するかもしれません。
随分昔からの明細書で、書く人によって項目が変わるので、その数フィールドが必要で、
かといってその明細書を改稿するにも、レガシーな方が多く、
使いやすさから言っても現行のものをそのままDB化したものを希望されています。。

>そんなに多くの項目がある明細書を、本当にお客さんにペラで見せるのですか？
はい‥。見た目は普通のどこにでもあるA4明細書です。
ただ他と違うのは、オプション欄があるので、オプションがない時は空白部が多いことぐらいですね。
オプション欄を別シートで‥、ということも前述の理由でできなさそうです。。

>もしお金の問題が絡むなら、せめて MySQL を候補に入れた方がいいです。
近いうちに、社内の売上一覧も作成することになると思うので、AccessでDBの基本を身に着け、MySQL等検討したいと思います。

貴重なご意見、参考になりました。ありがとうございました。

お礼日時：2006/08/29 08:50