テーブルの設計についてアドバイスください

質問

MySQL5を使用しています。

あるプレゼントコンテンツを作ろうとしているのですが、1箇所、懸念点がありなにかいい方法がないかアドバイス頂ければと思います。

presets（プレゼントテーブル）
-------------
id

users（会員テーブル）
-------------
id

tickets（応募可能テーブル）
-------------
id
present_id
user_id
left_ticket（応募可能数）

logs（応募履歴テーブル）
-------------
id
present_id
user_id
is_prize（当選したかどうか）

仕様
・各プレゼントへの応募可能数は、ユーザ／プレゼントによって違う（=left_ticket）

プレゼントを新規登録する際に、ticketsテーブルに全ユーザ分のレコードを登録しなくてはならず、数十人程度なら良いんですが、数百人～数千人となると非現実的かなと思っています。

なにか良い方法はありますでしょうか？

回答No.2

jjon-com · ベストアンサー

> 各プレゼントへの応募可能数は、ユーザ／プレゼントによって違う

というランダムな前提であり，それ以外に規則性も条件もないのであれば，数百人～数千人であろうとも全ユーザ分のレコードを登録するのは必要かつ現実的な作業でしょう。

そうではなく，例えば，
会員Aは3個応募可能，会員Bは2個応募可能，「それ以外の会員は1個応募可能」というような規則性や条件を現実に用いているのであれば，それをシステムに反映させればよいと思います。
応募可能テーブルに対して会員Cでの検索が失敗したらプログラム内で応募可能数を割り当てるとか，「それ以外の既定の会員」という状態に会員idを割り当てて応募可能テーブルに登録しておくとか，そういうことです。

お礼

ありがとうございます。
大変参考になりました。
プログラム側である程度吸収できそうなので、そちらで行います。

回答No.1

Tarepanda_club

はじめまして。

どんな仕組みで応募可能数が変動するのか分らないので、少し予測がはいります。ごめんなさい。
数百人～数千人のユーザに応募可能数をランダムに入力するとは考えにくいので、多分ユーザのランクとプレゼントごとの係数で算出されるとすれば、です。

presets（プレゼントテーブル）
-------------
id　係数

users（会員テーブル）
-------------
id　ランク

tickets（応募可能テーブル）
なし

にしてユーザのアクセスごとに算出するようにされてはどうですか？
入力画面にあと●回可能ですと表示させたり登録時に可能数を確認後insertを走らせれば運用できるかと思います。
確かにユーザ数*プレゼント数の応募可能テーブルはかなりの速度で大きくなるでしょうし、大変そうですね。

ご期待の答えになればいいのですが。

お礼

ありがとうございます。
詳細説明できず申し訳ありませんでしたが、大変参考になりました。