MySQL5.1の質問です。

フィールドが300くらいのテーブル設計ってありでしょうか?
レコード数は多くて1万ほどだと思います。
フィールドとは商品数で1万とはユーザー数を想定しています。
在庫管理を行うテーブルを作ろうと思っていますが、MySQLってこんな使い方ってするのでしょうか?
以下のようなテーブルを考えています。



テーブル名:item_tbl
id, name
1, aaa
2, bbb
3, ccc
4, ddd
5, eee


テーブル名:user_tbl
id, user
3, yama
5, kawa
6, tani
9, hoge


テーブル名:zaiko_flag
id, 1, 2, 3, 4, 5.....
3, 0, 1, 0, 0, 1.....
5, 1, 1, 0, 1, 1.....
6, 0, 0, 1, 0, 1.....
9, 0, 1, 1, 0, 0.....

回答の条件
  • 1人2回まで
  • 13歳以上
  • 登録:2011/03/31 23:52:15
  • 終了:2011/04/02 16:23:34

回答(5件)

id:windofjuly No.1

うぃんど回答回数2625ベストアンサー獲得回数11492011/04/01 00:36:46

ポイント40pt

>MySQLってこんな使い方ってするのでしょうか?

100%無いとは言いませんけれど(MySQLに限らず)データベースでは基本的に行わないです

itemが1つ増減するだけでプログラムの改変が必要になるという面倒なシステムをお望みであれば別ですが…

 

>テーブル名:zaiko_flag

>id, 1, 2, 3, 4, 5.....

>3, 0, 1, 0, 0, 1.....

zaiko_flagテーブルは「user_id,item_id,フラグ」としてしまえばよろしいでしょう

300アイテム x 1万ユーザー = 300万レコードとなってしまってもインデックスをつけてあれば一瞬で抜き出せます

 

縦の物を横に並べて表の形に整えたりするのはphpなどの方で行えば良いです

(MySQL側でも出来ますがphpなどのフロントエンドで行うほうが楽です)

id:seadwell

> 面倒なシステムをお望みであれば別ですが…

いえいえ、

ここは面倒にならないようちゃんと考えましたが、ただ300ものフィールドってプロの方って行うのか聞いてみました^^;

もしプログラム改変が面倒でなければ300は問題ないのでしょうか?


> 300万レコードとなってしまってもインデックスをつけてあれば一瞬で抜き出せます

それは考えてなかったです。

だいぶ頭が柔らかくなりました。

ありがとうございます。

2011/04/01 01:34:16
id:taroe No.2

taroe回答回数1099ベストアンサー獲得回数1322011/04/01 00:51:54

ポイント20pt

>フィールドが300くらいのテーブル設計ってありでしょうか?

実際現場でもそういうテーブルは存在します。

ありかどうかといえば、ありです。

集計表などを格納するときに、そのような設計をすることもあります。

もちろん集計表の格納を違う方法でテーブルに持つことも可能ですので

どちらかよいかは、システム要件や性能要件によります。


フィールドが300、レコード数は多くて1万ですので、どちらを選択しても

問題になることはないかと思います。

id:seadwell

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

MySQLっておもってたより優秀なんですね^^;

現場でのご意見勉強になります。

2011/04/01 01:46:26
id:asuka645 No.3

あすか回答回数856ベストアンサー獲得回数972011/04/01 11:13:26

ポイント20pt

フィールドが300くらいのテーブル設計ってありでしょうか?

実装は可能ですが、設計としてはよろしくありません。


ご質問の在庫管理テーブルのカラムが、

id 2011年1月 2011年2月 2011年3月

のようなイメージを考えておられるようでしたら、これは正規化されていません。

より正しくは、

item_id 年月 在庫数

とすべきです。

つまり、1つの商品に付き複数の在庫テーブルを有することになります。

id:seadwell

こんにちは。

>実装は可能ですが、設計としてはよろしくありません。

ですよね。


今回は、あるか?ないか?だけ管理するつもりでした。

しかし、ご提案のイメージはそのような必要が出てきたときに使わせてもらいます。

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

2011/04/01 11:59:29
id:hanako393 No.4

hanako393回答回数1142ベストアンサー獲得回数872011/04/01 16:50:06

ポイント20pt

フィールドが300くらいのテーブル設計ってありでしょうか?

正規化されていてもフィールドが200を超えてるテーブルは何回も見たことはあります。


今回は、あるか?ないか?だけ管理するつもりでした。

その程度でしたら良いと思います。

id:seadwell

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

コメントにもありますが、回答者1の方の策で行こうと思っていたのですが、300アイテムもの在庫テーブル一括更新や登録の良い策

が見つからなければ、ほんとは嫌ですが当初の予定通り300フィールドを持たせたいと思います。

2011/04/01 17:33:52
id:prehell No.5

prehell回答回数7ベストアンサー獲得回数02011/04/01 17:21:45

ポイント20pt

>複数の在庫フラグをいっきにONにしたりOFFにする方法が解らないのでそこで止まっています。

>例えば、ユーザーが在庫フラグをすべてONにしたい場合、書き込みをforeachで300回繰り返すという処理でよろしいのでしょうか?

そうです。

理想的な設計ではどこかにひずみがある場合

あえて理想的な設計をしないというのが今回のケースではないのかな?

ケースバイケース

id:seadwell

>そうです。

残念なお知らせでした。

なにか私の知らない方法があるのかと期待しましたが ^^;


更新を優先するか?抽出と後の改変を優先するか?天秤にかけないといけないのですね。

どちらが頻度が高そうかじっくり考えてみます。

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

2011/04/01 19:06:15
  • id:windofjuly
    うぃんど 2011/04/01 02:40:01
    >現場でのご意見
    頻繁に一覧表を閲覧する必要性がある場合には毎度毎度集計させる時間が勿体無いので「定期的あるいはデータ書き込み/変更時点であらかじめ集計を行っておいて必要時には結果データを見るだけですむようにしておく」という手段を用いることはありますが、その場合は、その結果を格納しておくためのテーブル(taroeさんが集計表と言っているものです)を別途用意する形を取ります
     
    >プログラム改変が面倒でなければ300は問題ないのでしょうか?
    MySQL側ではフィールド数が多いことによるパフォーマンス低下は特にありません
    プログラム側ではフィールド数が多いことによって煩雑になる可能性が高く、バグやプログラムミスも誘発しやすくなります
    ユーザーインターフェース、データベースとのやりとり、それらの制御プログラムなどの関連する部分を改変し、動作テストを一通り行って…という一連の作業時間を考慮した上で面倒ではないという事であれば300フィールドであろうと500であろうとご本人の自由です
     
    回答1が基本、回答2が別途集計表を用意するという1つの提案と捉えるとよいでしょう
  • id:seadwell
    こんにちは。
    コメントでのフォローありがとうございます。
    windofjulyさんの提案を軸に考えているのですが、複数の在庫フラグをいっきにONにしたりOFFにする方法が解らないのでそこで止まっています。
    例えば、ユーザーが在庫フラグをすべてONにしたい場合、書き込みをforeachで300回繰り返すという処理でよろしいのでしょうか?
    よろしくお願いします。
  • id:sayo221sayo
    そういうのを「他人のふんどしで相撲を取る」と言う。
  • id:windofjuly
    うぃんど 2011/04/01 20:48:03
    >複数の在庫フラグをいっきにONにしたりOFFにする方法
     
    できますよ
    たとえばユーザーIDが5のレコードはフラグを1にする
    UPDATE zaiko_flag SET フラグ = 1 WHERE user_id = 5;
    たとえばユーザーIDが5でアイテムが2から4のものはフラグを0にする
    UPDATE zaiko_flag SET フラグ = 0 WHERE user_id = 5 AND item_id BETWEEN 2 AND 4;
    ほかにも色々な組み合わせが可能ですから、条件を入力するWEBフォームを用意して、そこで入力された内容から上のようなSQL文をphpで作成、SQLをMySQLで実行すればよいと言うことになります
  • id:seadwell
    > 入力された内容から上のようなSQL文をphpで作成、SQLをMySQLで実行すればよいと言うことになります
    こんなこと考えもしませんでした。
    私には相当ハードルが高いですが、いずれチャレンジしてみたいと思いますので今回の設計はwindofjulyさんのご提案を拝借させてください。
    ありがとうございました。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません