長谷です。

> 野本さま。
> カナリヤです。

こんにちは

> やはり、Accessは便利だけれども、離れて正解だったのですね（＾＾；

ケースバイケースじゃないですか。

何でもかんでも MySQL じゃないとダメとか、Access じゃないと
ダメとかという事ではないと思います

Access に色々問題はあるにせよ、使い方にもよりますが、データ
がせいぜい100件なり1,000件程度なら Access なり FileMaker で
十分ですし、PC が１台だけなら C/S にすることもないのです。

ただ、DB へ突っ込むデータは、ある時間単位で区切って切り離さ
ないと肥大化する一方ですし、その切り離しができないなら、MySQL
の方がいいんでは、と思いますね。

> テーブル情報のみAccessで作っておいて、後からSQLサーバへ
> 移行する、

DB のテーブルの基本構造は、その用途によって練りに練って考え
なければなりませんから、既存で Access が動いていて変えようが
ないものならそれもしょうがないですが、そうでないならあまり
賢明な策とはいえないのでは、と思います

> SQLとAccessをつなげる、という方法もあるらしい

GUI な View の代りとして ODBC 接続して内容を見る、程度なら
それはいいんじゃないでしょうか。ただ、せっかく MySQLAdmin
という便利なものがあるので、その必要もないかとは思うんで
すけどね。

> これなら最初からMySQL＋PHPで
> 作った方が良いのではないか・・・？

ここは慣れてる言語でいいんじゃないかと^^;

スクリプト系は PHP だけでなく perl や Ruby もあります。
Java に慣れてるなら Servlet or JSP にするのも手です。
コンパイラ言語からだって操作できます。実際に私は C++ でやって
ました。

でも規模の問題もありますが、開発効率を考えると言語を覚えながら
．．．でもスクリプト系の方がいいかもしれませんね。

> 当然ここで、商品一覧の中には、仕入先の名前と繋がっているし
> 顧客情報の中には、購入してもらった商品と繋がっているのですよね。
> このつながりがリレーショナルだというのはわかります。
> で、ここでテーブルを作成した時には、商品の中の仕入先名のフィールド名と
> 仕入先情報のなかの仕入先会社名のフィールド名が同じ、というだけで
> テーブルAの○フィールドとたーぶるBの○フィールドが繋がっていますよ、という
> 情報は、MYSQLでコマンドを打ってテーブルを作っていく作業では
> 入力しなくて良いものなのでしょうか・・・・？

MySQL そのものから話題はずれますが、基本的にリレーショナルの
考えはそれで間違っていないと思います。

ぶっちゃけていえば、リレーショナルは幾つかのテーブルにデータ
を分けて格納し、連動させるということです。例えばご質問のよう
なシステムでは、仕入れ元というのは大体決っているようなもので、
そうそう変動はないでしょう？だからここはメインのテーブルとは
切り離して、別のテーブルにした方が良いですね(データ量も節約
できるし)。
そうすると、メインのテーブルでは「仕入先情報テーブル」から
予め登録されている仕入先のインデックスだけ入れておけばいいん
です。画面上ではリストボックスが表示されるようになるのがいい
でしょう。

と言う訳で、

> それぞれのテーブルで繋がっている情報というのは、PHP画面で
> 「実行」ボタンを押された時に、AテーブルのAフィールドと
> BテーブルのAフィールドの二箇所に入れてね、という命令を
> 与えるだけのものなのでしょうか・・・・？

ではなくて、Ｂテーブルに予め仕入先情報を登録しておいて、
ＡテーブルのＡフィールドのみ更新すればいいのです。

> Accessを使っていてとても便利だったのは、”クエリ”という機能を使って
> あらかじめ後に検索したい事などをテーブルに情報が入ったら
> どんどん勝手に計算・集計・並べ替え・などをしてくれていた事なのです。

> MySQLにも、クエリというのがあると思うのですが、これも、調べたい事を
> PHPなどから毎回命令するしかないのでしょうか・・・？
> それとも、MYSQLでテーブルを作るように、クエリで、予めいくつもある
> テーブルから、後に必要な情報をまとめておけるものなのでしょうか・・？

野元さんも仰っておられるように、クエリとは通常、データベース
エンジンに発行するSQL文そのものを指します。Access はその SQL
文をほぼ自動で作成してくれるので便利にみえるのです。

MySQL ならば、SQL 文は自分で書かなければなりません。
従って Access のように、最初から用意されていたり、自動で書け
る訳ではないんです。ですので「調べたい事をPHPなどから毎回命令
するしかない」んです。

> 私が目指すお買い物籠などを
> 作ろうとした時に、Ａｃｃｅｓｓは不向き

ちなみにどの辺からそう思ったんですか？

私が知っている範囲では、確かにその用途では不向きかもしれません。
Microsoft ではこのようにしか言って居ませんが．．．
http://www.microsoft.com/japan/business/offerings/LOB/advantage/default.asp

詳しいところはこんなのどうでしょう。
http://www.naboki.net/access/achell/achell_02.html

経験上、アクセス権を設定するとかより、一番問題になるのがデータ
の破壊です。上記のとおり、Access 2000以降では一件(１行)単位で
明示的にデータをロックできるようになりましたが、それでも一時に
買い物が集中すると危ないかもしれません(MS も上記でそのように
臭わせていますよね)。そもそも Access はそういう用途を想定して
作られてはいないのです。

尚、FileMaker ならば Server 版でなくても５セッションまでは
保証しているようです。
http://www.filemaker.co.jp/products/fm_requirements.html

ただ FileMaker は元々 Mac から出てきている為か、UI が変わって
いますので、Access に慣れちゃうと操作に戸惑うかもしれませんね。

> そも、Accessと比べて悩んだのが迷路の始まりだったようです。

いえ、システムにあっては様々なソリューションを比べて情報を
集め、どれがその用途に適しているかを決めなければなりません。
最適解というのはあってないようなものですから、良く調べて
悩んでやってみるのも勉強のウチです。

-- 
長谷 <VYG01106@xxxxxxxxxx>